Re: [Quickfixj-users] Question about : Race Condition/NPE onSession.disconnect()

[Steve B. <st...@te...>]

> Recently I get the same error as bug QFJ-211, and I agree with Steve Bate 
> and Toli Kuznets that the reason is race condition. But I don't agree with

> the solution. Cause "Modified Session.disconnect to eliminate the race 
> condition." only solve the NPE problem. If in class AbstractIoHandler 
> sessionClosed()'s quickFixSession.disconnect() is executed before in the 
> Session class nextLogout()'s disconnect(), then the disconnect() will be 
> executed twice. And the application.onLogout() will be executed twice.(I 
> have seen it happens) That's a bug and should be avoid. I am thinking 
> if we just delete the following code in AbstractIoHandler 
> sessionClosed(), I think the problem will be solved.
>              if (quickFixSession.hasResponder()) {
>                 quickFixSession.disconnect();
>             }
>
> how do you think that? Am I understood?

Hi Mike,

This is a different problem than the NPE described in QFJ-211. The code
in AbstractIoHandler is there to process a socket disconnect that occurs
without a logout message. This is treated as an implicit logout. The
state is reset and the onLogout callback is invoked. In the case of
a logout message being received and then the socket being disconnected,
my understanding is that MINA will process those events sequentially.
Although disconnect will be called a second time when the socket is
disconnected, the session state is checked and onLogout is not called.
In this scenario, I don't think there is a race condition.

However, if a Session is logged out locally at about the same time as the
socket is disconnected or the counterparty sends a logout message, I
can see the possibility of a race condition where disconnect is called
from two threads (session timer and MINA) and the onLogout could be
called twice. I'll add a synchronized block around the state check
related to the onLogout callback. This should solve the double callback.

Thanks for the problem report.

Regards,

Steve