[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [certi-dev] Deadlock with jcerti
From: |
Jan-Patrick Osterloh |
Subject: |
Re: [certi-dev] Deadlock with jcerti |
Date: |
Tue, 09 Oct 2012 10:43:19 +0200 |
User-agent: |
Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 |
Hi!
--- Quoted from Eric Noulard (Date: 08.10.2012 21:27): ---
> 2012/10/8 Jan-Patrick Osterloh <address@hidden>:
>> Hi all,
>>
>> I'm currently using jcerti in my environment, and I have troubles with
>> some "deadlock". During initialisation, my program hangs in
>> rtia.publishObjectClass(classHandle, attributes);
>> The method does not return and hangs. Any idea what that could be, or I
>> can debug this?
> I don't really what could be the cause of that.
>
> Does this *always* happend or does it sometimes work?
Currently it is reproducible, so it happens always, always at the same
point. Also I had one afternoon (Friday) where it worked again, but when
I tried yesterday, same problem occoured.
> Is your application using rtia object in a concurrent fashion?
> i.e. does several thread use the same rtia object ?
Well, my Federate is a Thread (or to be correct, it implements Runnable
and is started in a Thread).
> If this is the case may be there is a race, could you try to serialize
> the access to the object using some Java lock or monitor?
Threading was also my first idea, therefore I tried to make it
thread-safe by using a "java.util.concurrent.locks.ReentrantLock" as
Semaphore for each rtia call, but it makes no difference between using
the lock or not (but maybe I must use it more often). I even tried to
use it without beeing a thread, but it makes no difference.
How much threading is used in jcerti itself, i.e. how are the callbacks
handled? Are they called in an extra thread? I used the UAV example as a
start for implementing my Federate.
>
> Concerning the debugging you should be able to debug into the call
> but if it is racy may be debugging it would make the problem disappear...
>
> You may try to bump the logger trace level, that way we may
> have more clue were the deadlock occurs.
>
> I don't remember right now how to do it.
> May be something like defining the jcerti.logLevel to appropriate value is
> the way to go. If you don't find your way in the Java code I'll find out
> tomorrow.
>
I've seen somewhere that the debug level is read from a property file,
I'll check that.
JPO
--
Dipl. Inform. Jan-Patrick Osterloh
FuE Bereich Verkehr | R&D Division Transportation
Human Centered Design Group
OFFIS
FuE Bereich Verkehr | R&D Division Transport
Escherweg 2 - 26121 Oldenburg - Germany
Phone/Fax: +49 441 97 22-524/502
E-Mail: address@hidden
URL: http://www.offis.de
signature.asc
Description: OpenPGP digital signature
- [certi-dev] Deadlock with jcerti, Jan-Patrick Osterloh, 2012/10/08
- Re: [certi-dev] Deadlock with jcerti, Eric Noulard, 2012/10/08
- Re: [certi-dev] Deadlock with jcerti,
Jan-Patrick Osterloh <=
- Re: [certi-dev] Deadlock with jcerti, Jan-Patrick Osterloh, 2012/10/09
- Re: [certi-dev] Deadlock with jcerti, Jan-Patrick Osterloh, 2012/10/09
- Re: [certi-dev] Deadlock with jcerti, Andrej Pancik, 2012/10/10
- Re: [certi-dev] Deadlock with jcerti, Jan-Patrick Osterloh, 2012/10/11
- Re: [certi-dev] Deadlock with jcerti, Eric Noulard, 2012/10/12
- Re: [certi-dev] Deadlock with jcerti, Jan-Patrick Osterloh, 2012/10/12
- Re: [certi-dev] Deadlock with jcerti, Jan-Patrick Osterloh, 2012/10/15
- Re: [certi-dev] Deadlock with jcerti, Eric Noulard, 2012/10/15
- Re: [certi-dev] Deadlock with jcerti, Jan-Patrick Osterloh, 2012/10/15
- Re: [certi-dev] Deadlock with jcerti, Eric Noulard, 2012/10/16