[QFJ-814] Sequence Reset Fails Created: 16/Oct/14  Updated: 12/Nov/18  Resolved: 16/Jul/18

Status: Closed
Project: QuickFIX/J
Component/s: Engine
Affects Version/s: 1.5.0
Fix Version/s: 1.6.0

Type: Other Priority: Default
Reporter: Rahul Gaur Assignee: Unassigned
Resolution: Duplicate Votes: 1
Labels: sequence,

Attachments: PDF File fix-43_VOL-2_with_Errata_20020920.pdf    
Issue Links:
Duplicate
duplicates QFJ-673 QFJ sequence problem following inboun... Closed
is duplicated by QFJ-928 SequenceReset not processed when out ... Closed

 Description   

Hi All,

Here are the steps:

1. Our FIX engine receives an out of sequence messages with MsgSeqNum(s) => 200938 -> 200941 -> 200939 (No 200940 received).

2. It complains => "MsgSeqNum too high, expecting 200939 but received 200941" and sends a 'ResendRequest(35=2)' with 'BeginSeqNo=200939'.

3. Before receiving the reset message it receives two more messages with MsgSeqNum(s) => 200942 -> 200943.

4. It then receives the 'SequenceReset(35=4)' with:
a) NewSeqNo = 200944
b) MsgSeqNum = 200939
c) PossDupFlag = Y
d) GapFillFlag = Y

5. No trace in the logs as to whether the 'SequenceReset' is handled or not.

6. It then receives a message with MsgSeqNum = 200944 and complains => 'MsgSeqNum too high, expecting 200940 but received 200944'. This error message persists for all subsequent messages and our engine is not able to recover from it as the MsgSeqNum = 200940 is never received.

At step 6, shouldn't the engine ignore all messages from 200939-200943 and start afresh from 200944.

Thanks
Rahul

 Comments   
Comment by Christoph John [ 16/Oct/14 ]

Could you please test this with a more recent QF/J version? The current version is 1.5.3 and there was also a related bug fixed in 1.6.0 (QFJ-673) which is only available as snapshot at the moment (http://www.quickfixj.org:8085/browse/QFJ-GIT/latest/artifact/shared/qfj-zip/).

Comment by Rahul Gaur [ 26/Nov/14 ]

Hi John,

On digging more on this issue and on checking the FIX 4.3 protocol specification we find that our FIX engine behaved correctly at 'step 5' by ignoring the Sequence Reset(Gap Fill) message. Please find attached the specs and see the page 23 & 49. As per the specs:

Sequence Reset (Gap Fill)
a. Receive Sequence Reset (Gap Fill) message with NewSeqNo > MsgSeqNum and MsgSeqNum > than expect sequence number Issue Resend Request to fill gap between last expected MsgSeqNum &
received MsgSeqNum.
b. Receive Sequence Reset (Gap Fill) message with NewSeqNo > MsgSeqNum and MsgSeqNum = to expected sequence number Set next expected sequence number = NewSeqNo
c. Receive Sequence Reset (Gap Fill) message with NewSeqNo > MsgSeqNum and MsgSeqNum < than expected sequence number and PossDupFlag = "Y" Ignore message
d. Receive Sequence Reset (Gap Fill) message with NewSeqNo > MsgSeqNum and MsgSeqNum < than expected sequence number and without PossDupFlag = "Y" ....
e. Receive Sequence Reset (Gap Fill) message with NewSeqNo <= MsgSeqNum and MsgSeqNum = to expected sequence number ...

Could it be that at step 1. or step 2., the FIX engine was suppose to send one more 'ResendRequest(35=2)' with 'BeginSeqNo=200940' ?

Thanks
Rahul

Comment by Christoph John [ 27/Nov/14 ]

Hi Rahul,

you are right, the SequenceReset with a seqnum lower than the expected seqnum and PossDupFlag is (and should be) ignored. But maybe a message in the logs would be helpful though.
Was the other side also a QF/J engine? I've heard one user reporting a similar problem on the mailing list.

Cheers,
Chris.

Comment by Rahul Gaur [ 15/Jul/18 ]

Hi John,

This can be closed as this got fixed in the newer version of QuickfixJ

Thanks
Rahul

Comment by Christoph John [ 16/Jul/18 ]

Hi Rahul,
thanks for the information!
Cheers,
Chris.

Generated at Sat Nov 23 10:45:45 UTC 2024 using JIRA 7.5.2#75007-sha1:9f5725bb824792b3230a5d8716f0c13e296a3cae.