mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christoph John <christoph.j...@macd.com>
Subject Re: observing hangs after update to MINA 2.0.14
Date Fri, 14 Oct 2016 21:47:00 GMT
Hi Emmanuel,

I think I have found the problem in our code and it is most likely related to 
https://issues.apache.org/jira/browse/DIRMINA-1025 .
In the code we were calling ioSession.closeNow(). This worked before but due to the changed
flushing 
behaviour messages sometimes got lost on disconnect which lead to hangs because expected messages

were not received.

I have another question regarding this. Here is the code that is called when disconnecting
the session:
----------
         // This is primarily to allow logout messages to be sent before
         // closing the socket. Future versions of MINA may have support
         // in close() to force all pending messages to be written before
         // the socket close is performed.
         //
         // Only wait for a limited time since MINA may deadlock
         // in some rare cases where a socket dies in a strange way.
         for (int i = 0; i < 5 && ioSession.getScheduledWriteMessages() > 0;
i++) {
             try {
                 Thread.sleep(10L);
             } catch (InterruptedException e) {
                 Thread.currentThread().interrupt();
             }
         }

         // We cannot call join() on the CloseFuture returned
         // by the following call. We are using a minimal
         // threading model and calling join will prevent the
         // close event from being processed by this thread (if
         // this thread is the MINA IO processor thread.
         ioSession.closeOnFlush();
----------

This code was already there when we used MINA 1.x, so I do not know if the for-loop is still

necessary when calling closeOnFlush() afterwards. It also did not help in our situation when
we 
still called closeNow(). So either waiting 5*10 milliseconds was too short or there were no

scheduled write messages present.

What about the comment about the deadlock? If I understand correctly then I have a probability
of 
hitting https://issues.apache.org/jira/browse/DIRMINA-893 ?? So I should probably go for await()
or 
await(timeout)?

Thanks in advance for your help.
Best regards,
Chris.


On 26/09/16 11:22, Emmanuel Lécharny wrote:
> Le 26/09/16 à 09:01, Christoph John a écrit :
>> Until now I could not reproduce the problem reliably. However, I think
>> it might not be a "hang" but have to do with the changed behaviour
>> regarding flushing that has been fixed in MINA 2.0.14 (DIRMINA-1025/1021)
>> E.g. the tests wait for a message to arrive that the other side has
>> sent but it doesn't seem to be received.
>>
>> I guess I'll have to review the closeNow/closeOnFlush calls in
>> QuickFIX/J then? Maybe it is only related to the test suite, though.
> I think you sent a test case that reproduce the issue (AFAIR). I ran
> this test and got a hang, if I try to close both ends, that is what I'd
> like to investigate.
>
> Sadly, I have been pretty busy lately, and I had to cut a new release
> 2.0.15 urgently, due to a big bug in SSL, so I didn't had chance to go
> any further. I hope to have time to do that this week.
>

-- 
Christoph John
Development & Support
Direct: +49 241 557080-28
Mailto:Christoph.John@macd.com
	


http://www.macd.com <http://www.macd.com/>
----------------------------------------------------------------------------------------------------
	
----------------------------------------------------------------------------------------------------
MACD GmbH
Oppenhoffallee 103
D-52066 Aachen
Tel: +49 241 557080-0 | Fax: +49 241 557080-10
	 Amtsgericht Aachen: HRB 8151
Ust.-Id: DE 813021663

Geschäftsführer: George Macdonald
----------------------------------------------------------------------------------------------------
	
----------------------------------------------------------------------------------------------------

take care of the environment - print only if necessary

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message