Linux

I think we cannot do anything about it without an exact description how to reproduce or a unit test. Did you try to send a message to the same Session from two different threads??

Hi Christoph,

Sorry for the delay.

We are disconnecting the trading session when the streaming session is disconnecting.
Is it a problem ? is it a bad practice ?

If it's a bad practive, we would like to disconnect all the sessions of a user if one of them is disconnected ? What is the correct way to do this ?

This is our current code for disconnect all the sessions of user called in the onLogout method in the Application interface

Session streaming = sessionData.getStreamingSession();
		Session trading = sessionData.getTradingSession();
		logger.info("--> logout Streaming....");
		sendLogout(streaming, reason);

		logger.info("--> logout Trading....");
		sendLogout(trading, reason);
		
		sleep(1000);
		logger.info("--> disconnect Streaming....");
		try {
			if (streaming != null) {
				streaming.disconnect(reason, true);
			}
		} catch(IOException ex) {
			logger.error("error while disconnect streaming", ex);
		}

		logger.info("--> disconnect trading....");
		try {
			if (trading != null) {
				trading.disconnect(reason, true);
			}
		} catch(IOException ex){
			logger.error("error while disconnect trading", ex);
		}

The "Session" that you are getting via getStreamingSession() or getTradingSession() is a quickfix.Session, right??
What does the code of the sendLogout() method that you are calling look like?

I noticed that you are using a rather old version of QFJ (1.5.3). At least that is what you entered into the issue description. There were some concurrency fixes done since that version, e.g. QFJ-738 (which looks a little like the problem you are having) or QFJ-790. Maybe you could try a more recent version. 1.6.4 is the current version.

Apart from that I would not suggest to call Session.disconnect() from different threads and also to not send any Session-level messages by yourself (e.g. Logon, Logout).
Actually it should be enough if you called Session.logout(). That should trigger a Logout and disconnect of the FIX session. If you want to re-enable the Session then just call Session.logon().

Hope that helps,
Chris.

Hi Christophe,
Yes this is a QuickFix session instance.

The method sendLogout() above is called from the onLogout method from Quickfix.Application interface

@Override
	public void onLogout(SessionID arg0) {
		Thread.currentThread().setName(arg0.getTargetCompID());
		fixApi.handleUserDisconnect(arg0);
	}

the fixApi.handleUserDisconnect() disconnect the user in our system and disconnect all the sessions for the current user (Streaming and trading).
As you mentionned, i send a logout message to the streaming session via the trading thread. Is it a problem ?

Thanks for your assistance

Umm, yes, as I was suggesting in my earlier comment: you shouldn't call disconnect() from a separate thread. Actually, you shouldn't call it at all and leave the whole session management / connect / disconnect stuff to QFJ. Please use Session.logon() and logout().

Chris

Thanks christoph,

So to clarify, if i must disconnect the streaming session via the trading thread, I need to remove the disconnect method call and using the logout method only ?
If i understand you think that the deadlock is caused by the disconnect method call from another thread ?

THanks

Yes, as I was suggesting in my earlier two comments you should remove the disconnect() call and use the logout() method only. If you got an Initiator, do not forget to call logon() afterwards, otherwise it will not try to reconnect. If you got an Acceptor, the you do not need to call logon() afterwards.

The deadlock is probably caused by either the call of the disconnect() method from another thread or the call to sendLogout() while another message is still trying to be sent/received.

If you have further questions please direct them to the mailing list, since JIRA is the bug tracker. Thank you.
https://lists.sourceforge.net/lists/listinfo/quickfixj-users

Regards,
Chris.