[QFJ-513] Sequence gets reset even with ResetOnLogon, ResetOnLogout and ResetOnDisconnect all set to N. Created: 04/Mar/10  Updated: 15/Nov/12  Resolved: 05/Apr/10

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

Type: Bug Priority: Default
Reporter: Paul Michael Assignee: Unassigned
Resolution: Not a bug Votes: 0
Labels: None


 Description   

Below are some logs of the issue:

ABC-MARKET uses ResetOnLogon = Y
ABC-ORDER uses ResetOnLogon = N

10:27:49.581 EST INFO 3 - onLogout FIX.4.3:ABC-MARKET->XYZ
10:27:49.581 EST ERROR 3 - The FIX client FIX.4.3:ABC-MARKET->XYZ disconnected.

10:29:08.530 EST INFO 3 - >> 8=FIX.4.3|9=60|35=5|34=2286|49=XYZ|52=20100302-15:29:08|56=ABC-ORDER|10=252|
10:29:08.530 EST INFO 3 - << 8=FIX.4.3|9=64|35=5|34=2354|49=ABC-ORDER|52=20100302-15:29:08.530|56=XYZ|10=194|
10:29:08.542 EST INFO 3 - onLogout FIX.4.3:ABC-ORDER->XYZ
10:29:08.542 EST ERROR 3 - The FIX client FIX.4.3:ABC-ORDER->XYZ disconnected.

10:29:08.542 EST ERROR 3 - The next FIX.4.3:ABC-ORDER->XYZ Sending Sequence is expected to be: 2355

Sequence is reset for ABC-MARKET during reconnect (correct):

10:29:55.143 EST INFO cceptorIoHandler - MINA session created: /127.0.0.1:43238
10:29:55.143 EST INFO 3 - >> 8=FIX.4.3|9=80|35=A|34=1|49=XYZ|52=20100302-15:29:54|56=ABC-MARKET|98=0|108=30|141=Y|10=018|
10:29:55.143 EST INFO 3 - << 8=FIX.4.3|9=84|35=A|34=1|49=ABC-MARKET|52=20100302-15:29:55.143|56=XYZ|98=0|108=30|141=Y|10=221|
10:29:55.143 EST INFO 3 - onLogon FIX.4.3:ABC-MARKET->XYZ

Sequence is also reset for ABC-ORDER during reconnect (incorrect):

10:29:55.148 EST INFO cceptorIoHandler - MINA session created: /XX.XX.X.XXX:57274
10:29:55.171 EST INFO 3 - >> 8=FIX.4.3|9=78|35=A|34=2287|49=XYZ|52=20100302-15:29:54|56=ABC-ORDER|98=0|108=30|141=N|10=078|
10:29:55.171 EST INFO 3 - << 8=FIX.4.3|9=73|35=A|34=1|49=ABC-ORDER|52=20100302-15:29:55.171|56=XYZ|98=0|108=30|10=077|

Unfortunately, these are the only details I can provide for now, I'm still trying to get the exact configuration settings which caused the problem but the Reset flags as mentioned in the title are all set to N for ABC-ORDER.

I was told that this issue has occurred twice already in production (the logs are from prod) but I can't seem to create a test case which shows the exact error for this yet.

Thanks in advance.

 Comments   
Comment by Laurent Danesi [ 04/Mar/10 ]

Hi,

Could you provide us the SessionSettings and the event log, please?

Laurent

Comment by Paul Michael [ 05/Mar/10 ]

Thanks Laurent for the reply. After seeing the production logs and looking at the code, it looks like the problem is not with QuickFix/J but with our code.

Below is the scenario:

1. During EOD, the SocketAcceptor for ABC-ORDER is stopped.
2. There's a boolean flag that is triggered saying that EOD has begun.
3. The flag on step 2 will change the ResetOnLogon value to Y for ABC-ORDER.
4. The SocketAcceptor is restarted with value from step 3.
5. During startup of the SocketAcceptor, the flag for step 2 is changed to false (indicating EOD has completed).
6. Since the SocketAcceptor was started using ResetOnLogon = Y, re-logons cause the sequence to be reset and only way to fix is to stop/start Acceptor so the flag for EOD is now false and consequently ResetOnLogon used by initiator will now be false.

I have a feeling that we should be using the EOD functionality from QuickFix/J instead of our adhoc solution. But given this scenario I mentioned, and given that I'm not allowed to change much in code that's already in Production, can you recommend an alternative solution?

Currently, I'm gearing towards updating toAdmin() method to check whether our flag for EOD is true and if Y, perform the checks done inside generateLogon() of Session and set the ResetSeqNumFlag in the Logon message as necessary. One problem I see with this approach is that the resetState() method of Session is currently marked private and therefore inaccessible from the toAdmin() method of our Application implementation.

Anyway, I'll also try to update the ticket title/description to be more clear.

Many thanks.

Comment by Paul Michael [ 05/Mar/10 ]

The other approach I can think of (which is rather hacky) is to change the refreshOnLogon field of Session to non-final and provide a setter method so I can change the value to N after running EOD (which initially sets this to Y).

Can you tell me why this is a bad idea (aside from the fact that I need to make this adjustment for every new release of quickfixj)?

Anyway, thanks for your time and sorry for the newbie questions.

Comment by Steve Bate [ 05/Apr/10 ]

Those fields are final so they will be thread safe (due to immutability). We would need to make them volatile or synchronize them in some other way if they were mutable.

Generated at Thu May 02 09:35:02 UTC 2024 using JIRA 7.5.2#75007-sha1:9f5725bb824792b3230a5d8716f0c13e296a3cae.