Re: [certi-dev] Deadlock with jcerti

[Jan-Patrick Osterloh]

--- Quoted from Eric Noulard (Date: 12.10.2012 15:45): ---
> 2012/10/11 Jan-Patrick Osterloh <address@hidden>:
>> Hi Andrej,
>>
>> --- Quoted from Andrej Pancik (Date: 10.10.2012 21:41): ---
>>> did you try to run the code in the debug mode and stop the execution
>>> as soon as it hangs to observe where exactly it happens?
>>>
>> Yes, I finally succeed in debugging. It finally hangs in
>> MessageBuffer.receiveData(), line 303 in the inputStream.read();
>> According to the JavaDoc of InputStream, this method blocks until new
>> data is available. Maybe the sender is too fast and has send the data
>> already, without being received?
> I doubt it, this inputStream comes from the serverSocket.accept()
> in CertiRtiAmbassafor.java:146 which accept a connection
> from the rtia process that have been launched right before that.
>
> This socket cannot "loose" data, this is a TCP socket, the sender (rtia)
> would be blocked if the reader is not reading fast enough.

Ok, I see. My colleague mentioned problems with this, but he used UDP,
which is different. Anyway, the solution for this is also the problem,
see below!

>
>> That would explain why it works when I
>> start the debugging into file (this would slow down the RTIA process...)?
> I would rather have a look at rtia process initialization which "may" be racy
> when several PrettyDebug instance are used for different threads
> (1 for each federate).
>
> When "CERTI_DEBUG_FILE" is not defined then they "share" std::cerr,
> which may not be a very good idea since C++ standard I/O are not
> guaranteed to be thread -safe:
> http://stackoverflow.com/questions/6374264/is-cout-synchronized-thread-safe
>
Holy SH...that gave me a hint where the problem is!!

Can you do me a favour, and try again with the test I send you, but this
time enable in your environment some RTIA debug output? I have RTIA=D
enabled in my environment...

If you start a program in Java, with Runtime.exec or ProcessBuilder, you
HAVE to read the Input and Output Streams where the sub-process writes
to, because (as you mention before) if the streams are not read the
program blocks (same as in the TCP socked!). So what happens here is,
that the RTIA writes something on stdout/stderr, which is not retrieved
from Java side, so when the buffer is full, RTIA blocks in the print
function. That is why it worked on my and your computer, where probably
no debug flag is set.

When I start something from Java I always use a class for reading the
streams. If you agree, I will fix this in jcerti (read stream in extra
thread as long as rtia is open). I will send the patch to you Eric,
probably on Monday.

This made my Weekend!

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