[QFJ-212] Query behaviour on first Logon message from initiator when disconnected during session expiry Created: 13/Jul/07  Updated: 27/Jul/07  Resolved: 27/Jul/07

Status: Closed
Project: QuickFIX/J
Component/s: Engine
Affects Version/s: 1.0.4
Fix Version/s: None

Type: Other Priority: Default
Reporter: Rob Gilliam Assignee: Steve Bate
Resolution: Fixed Votes: 0
Labels: None
Environment:

Sun JVM 1.4


Issue Links:
Relates
relates to QFJ-218 Session time not checked while sessio... Closed

 Description   

[I searched to see if this had come up before, but couldn't find it - many apologies if this is a duplicate]

We have an issue when an acceptor receives the a Logon(A) message to start a new session from an initiator which was not connected at the time that the old session expired.

The Logon(A) message has 34=1 and 141=Y, so I would expect the acceptor to just go ahead with the new session. Unfortunately the logon message is being passed to Session.next(Message), which is getting false from a call to checkSessionTime() and so just calls Reset(), which sends a Logout(5) message (without having reset the sequence number) and disconnects (without even waiting for a Logout(5) response).

Our applicaiton is based on a slightly-customized version of QuickFIX/J (currently based on 1.0.4), so upgrading to a later version to see if this is resolved is not a quick and simple task, hence I thought I'd just ask a) if this is/was a known problem, and b) whether upgrading will resolve it before I investigate further next week.



 Comments   
Comment by Steve Bate [ 13/Jul/07 ]

The acceptor session checks the session time once per second regardless of whether there is a connection or not at the time. When it detects a session start time the session is reset and checkSessionTime will return true until the next session time interval. Do you have any idea why checkSessionTime is returning false when the logon arrives?

Comment by Rob Gilliam [ 16/Jul/07 ]

SessionTimerTask.run() (in 1.2.1 and 1.0.4) has the following:

if (session.hasResponder())

{ session.next(); }

which suggest to me that sessions which are not connected (i.e. have no socket connection established) will not have their session time checked (as Session.next() won't be called); this would match the behaviour we're seeing.

Or have I missed something somewhere?

Comment by Steve Bate [ 27/Jul/07 ]

I'll look into it more and let you know what I find out.

Comment by Steve Bate [ 27/Jul/07 ]

After looking at the code, guarding the session.next() based on the responder is not correct (because, as you've seen, the session time is not monitored). I've created a bug report (see the link in this issue). Thanks for reporting and investigating this issue.

Comment by Steve Bate [ 27/Jul/07 ]

See linked bug report for further information.

Generated at Fri Sep 20 22:15:17 UTC 2024 using JIRA 7.5.2#75007-sha1:9f5725bb824792b3230a5d8716f0c13e296a3cae.