[QFJ-356] CLONE -CLONE -First login attempt of initiator afterStartTime is responded with logout Created: 22/Oct/08  Updated: 26/Nov/08  Resolved: 26/Nov/08

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

Type: Other Priority: Default
Reporter: Leo Satoshi Fischer Assignee: Unassigned
Resolution: Fixed Votes: 1
Labels: None
Environment:

2003


 Description   

Hi Steve, it's been quite a while.
We are experiencing the bug detailed below.
Do you have a specific patch for this for 1.2.1, or is 1.3.0 stable enough
for production.

This could be related to a open bug about the timer events not being
processed in an acceptor while it's disconnected (QFJ-218). This would
cause the logout with the old sequence number to be sent the first time
someone connects. Subsequent connections should be ok and should use the
new session's sequence numbers. If we can complete the 1.3 release soon,
I'll have the fix in there. Otherwise, I'll patch 1.2.1 and release a
new version of that branch.

A temporary workaround is to call reset manually on the message
store before the new session start time.

Regards,

Steve



 Comments   
Comment by Leo Satoshi Fischer [ 24/Oct/08 ]

This is STILL an issue in 1.3.3.
Occasionally quickfix will send a logout before actually logging in a sesson at the start of a session in the morning.

It is caused by Session.checkSessionTime in CheckSession.next()
Basically while not in session time, every second, next is called and the session will reset the session, which causes a logout if there is a responder, and session state (creation time) to be reset.
Now, we pass the session start time, and a separate thread will call setResponder. This doesn't result in the session creation time being reset.
if we are lucky, the last call to next() was after the start time, and we won't reset the session.
If we are unlucky, checkSession looks at the session creation, determines we aren't the same session and calls reset, causing a logout to be sent.

Generated at Sun May 19 11:57:04 UTC 2024 using JIRA 7.5.2#75007-sha1:9f5725bb824792b3230a5d8716f0c13e296a3cae.