Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 1.3.3
-
Fix Version/s: 1.5.2
-
Component/s: Networking
-
Labels:None
-
Environment:Windows
Description
On the StartTime of session new Session is created and suppried to Session as Responder.
("sessionCreated" function in InitiatorIoHandler class)
But, this Session is reseted and "Logout" message is sent to acceptor on "next()" function in Session class.
This is caused by the management of session state in Session class.
The session state ( especially the session creation time) is reseted every 1sec during non Session time.
But on the new Session is created and suppried as Responder,
the session creation time is not updated and the new Session is treaed to not valid Session.
It should update session state (session creation time) when new Session is suppried.
/**
- Registers a responder with the session. This is used by the acceptor and
- initiator implementations.
* - @param responder a responder implementation
*/
public void setResponder(Responder responder) {
synchronized (responderSync)Unknown macro: { this.responder = responder; if (responder != null) { // reset session state here state.reset(); // force to verify session time lastSessionTimeCheck = 0; stateListener.onConnect(); } else { stateListener.onDisconnect(); } }}
We could solve this problem by this but, I'm not sure what' there side effect...
Attachments
Issue Links
Activity
This issue is of paramount importance I think – I recommend raising it's priority to major.
This bug is listed as since 1.3.3. Can anyone verify this is the case? We upgraded from 1.3.3 to 1.5 and started seeing this bug, so went back to 1.3.3 and stopped seeing it. Is it possible this bug is more prevalent in 1.5? Thanks
IIRC it showed in 1.3.3 only if you used a custom StartTime and initiated the connection.
Hi,
after spending some time working on this issue, I'm going to commit the changes (tomorrow at the latest) so we can have this corrected on 1.5.2. It still has an aftertaste of a workaround, so we should consider something more sophisticated for 1.6.0.
I picked up Beat's changes on the SessionState.reset() method. But this did not help in the case where a Session is created and immediately (inside one second) initiates or accepts a connection (this is happening when the Session is started within the session time). So I made sure that the first check in checkSessionTime() (which is called from the Session constructor) does not update the lastSessionTimeCheck. Hence on the next call (from Session.next()) the lastSessionTimeResult is evaluated again, returning true and in turn leading to the acceptance of the FIX connection.
I also made sure that outside session time a Logout is sent (see Paul's comment). The behaviour seemed to have changed in the meantime. When I tried to connect outside session time, I received a Logon immediately followed by Logout. I have changed Session.nextLogon() to reject the Logon outside of the session time.
Will also provide UnitTests. UnitTests and AcceptanceTests were successful.
Cheers,
Chris.
Guys,
I have found an ugly workaround.
When I was at a customer site, I wondered why they don't get hit by this bug. It seemed it was because they already load messages into the store right after gateway start (current order status information for the connecting client to be published at Logon).
After some tests I could verify that it works in most cases. But unfortunately it does not work if the FIX process is started outside the StartTime/EndTime range. QuickFIX will then reset the state again on first logon (leading to Logout to be sent as first message). I have not tested the case where the process is never stopped since our processes are restarted each night for EOD jobs.
So, all I did was to put some code into the onCreate() callback to increment the seqnum by 1 if it is still 1.
{ Session.lookupSession( fixSessionId ).getStore().incrNextSenderMsgSeqNum(); }if ( nextSenderMsgSeqNum == 1 )
Surprisingly, QuickFIX/J still sends out the first Logon attempt with seqNum = 1, although I incremented the seqNum when the quickfix.Session gets created. However, I have not the time to follow this up right now.
Good luck,
Chris.