Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#91 Infinite SequenceReset with PersistMessages=N

open
nobody
None
5
2012-06-06
2012-06-06
David Chan
No

I found that if (and only if) both QuickFIX acceptor and QuickFIX initiator have PersistMessages=N, then the acceptor (and I assume it is true for the initiator as well) may go into an infinite loop of SequenceReset.

How to reproduce:
* Start up acceptor.
* Start up initiator, which then login successfully.
* Send an order single.
* On acceptor, disable QuickFIX via QuickFIX Engine Web Interface.
* Verify that the session has logged out.
* On acceptor, enable QuickFIX via QuickFIX Engine Web Interface.

In my testing, this is the QuickFIX log on the acceptor side after the re-enable step:

FIX_0-0@GLOBAL :: QF_EVENT: Accepted connection from 127.0.0.1 on port 5001

FIX_0-0@FIX.4.2:EXECUTOR->42CLIENT1 :: QF_IN: 8=FIX.4.29=7235=A34=549=42CLIENT152=20120606-19:53:58.23856=EXECUTOR98=0108=3010=211

FIX_0-0@FIX.4.2:EXECUTOR->42CLIENT1 :: QF_EVENT: Received logon request

FIX_0-0@FIX.4.2:EXECUTOR->42CLIENT1 :: QF_OUT: 8=FIX.4.29=7235=A34=449=EXECUTOR52=20120606-19:53:58.24556=42CLIENT198=0108=3010=208

FIX_0-0@FIX.4.2:EXECUTOR->42CLIENT1 :: QF_EVENT: Responding to logon request

FIX_0-0@FIX.4.2:EXECUTOR->42CLIENT1 :: QF_EVENT: MsgSeqNum too high, expecting 4 but received 5

FIX_0-0@FIX.4.2:EXECUTOR->42CLIENT1 :: QF_OUT: 8=FIX.4.29=6935=234=549=EXECUTOR52=20120606-19:53:58.24956=42CLIENT17=416=010=049

FIX_0-0@FIX.4.2:EXECUTOR->42CLIENT1 :: QF_EVENT: Sent ResendRequest FROM: 4 TO: 0

FIX_0-0@FIX.4.2:EXECUTOR->42CLIENT1 :: session logon

FIX_0-0@FIX.4.2:EXECUTOR->42CLIENT1 :: QF_IN: 8=FIX.4.29=10235=434=443=Y49=42CLIENT152=20120606-19:53:58.25256=EXECUTOR122=20120606-19:53:58.25236=6123=Y10=229

FIX_0-0@FIX.4.2:EXECUTOR->42CLIENT1 :: QF_EVENT: ResendRequest for messages FROM: 4 TO: 4 has been satisfied.

FIX_0-0@FIX.4.2:EXECUTOR->42CLIENT1 :: QF_EVENT: Received SequenceReset FROM: 4 TO: 6

FIX_0-0@FIX.4.2:EXECUTOR->42CLIENT1 :: QF_IN: 8=FIX.4.29=6035=034=649=42CLIENT152=20120606-19:54:28.23856=EXECUTOR10=165

FIX_0-0@FIX.4.2:EXECUTOR->42CLIENT1 :: QF_OUT: 8=FIX.4.29=6035=034=649=EXECUTOR52=20120606-19:54:28.24056=42CLIENT110=158

FIX_0-0@FIX.4.2:EXECUTOR->42CLIENT1 :: QF_IN: 8=FIX.4.29=6935=234=749=42CLIENT152=20120606-19:54:28.24156=EXECUTOR7=516=010=042

FIX_0-0@FIX.4.2:EXECUTOR->42CLIENT1 :: QF_EVENT: Received ResendRequest FROM: 5 TO: 0

FIX_0-0@FIX.4.2:EXECUTOR->42CLIENT1 :: QF_OUT: 8=FIX.4.29=10235=434=543=Y49=EXECUTOR52=20120606-19:54:28.24456=42CLIENT1122=20120606-19:54:28.24336=7123=Y10=228

FIX_0-0@FIX.4.2:EXECUTOR->42CLIENT1 :: QF_EVENT: Sent SequenceReset TO: 7

FIX_0-0@FIX.4.2:EXECUTOR->42CLIENT1 :: QF_IN: 8=FIX.4.29=6035=034=849=42CLIENT152=20120606-19:54:58.23856=EXECUTOR10=170

FIX_0-0@FIX.4.2:EXECUTOR->42CLIENT1 :: QF_EVENT: MsgSeqNum too high, expecting 7 but received 8

FIX_0-0@FIX.4.2:EXECUTOR->42CLIENT1 :: QF_OUT: 8=FIX.4.29=6935=234=749=EXECUTOR52=20120606-19:54:58.24156=42CLIENT17=716=010=047

FIX_0-0@FIX.4.2:EXECUTOR->42CLIENT1 :: QF_EVENT: Sent ResendRequest FROM: 7 TO: 0

FIX_0-0@FIX.4.2:EXECUTOR->42CLIENT1 :: QF_IN: 8=FIX.4.29=10235=434=743=Y49=42CLIENT152=20120606-19:54:58.24256=EXECUTOR122=20120606-19:54:58.24236=9123=Y10=235

FIX_0-0@FIX.4.2:EXECUTOR->42CLIENT1 :: QF_EVENT: ResendRequest for messages FROM: 7 TO: 7 has been satisfied.

FIX_0-0@FIX.4.2:EXECUTOR->42CLIENT1 :: QF_EVENT: Received SequenceReset FROM: 7 TO: 9

FIX_0-0@FIX.4.2:EXECUTOR->42CLIENT1 :: QF_IN: 8=FIX.4.29=6035=034=949=42CLIENT152=20120606-19:55:28.23856=EXECUTOR10=169

FIX_0-0@FIX.4.2:EXECUTOR->42CLIENT1 :: QF_OUT: 8=FIX.4.29=6035=034=849=EXECUTOR52=20120606-19:55:28.24056=42CLIENT110=161

FIX_0-0@FIX.4.2:EXECUTOR->42CLIENT1 :: QF_IN: 8=FIX.4.29=7035=234=1049=42CLIENT152=20120606-19:55:28.24156=EXECUTOR7=716=010=079

FIX_0-0@FIX.4.2:EXECUTOR->42CLIENT1 :: QF_EVENT: Received ResendRequest FROM: 7 TO: 0

FIX_0-0@FIX.4.2:EXECUTOR->42CLIENT1 :: QF_OUT: 8=FIX.4.29=10235=434=743=Y49=EXECUTOR52=20120606-19:55:28.24456=42CLIENT1122=20120606-19:55:28.24336=9123=Y10=234

FIX_0-0@FIX.4.2:EXECUTOR->42CLIENT1 :: QF_EVENT: Sent SequenceReset TO: 9

FIX_0-0@FIX.4.2:EXECUTOR->42CLIENT1 :: QF_IN: 8=FIX.4.29=6135=034=1149=42CLIENT152=20120606-19:55:58.23856=EXECUTOR10=214

FIX_0-0@FIX.4.2:EXECUTOR->42CLIENT1 :: QF_EVENT: MsgSeqNum too high, expecting 10 but received 11

FIX_0-0@FIX.4.2:EXECUTOR->42CLIENT1 :: QF_OUT: 8=FIX.4.29=7035=234=949=EXECUTOR52=20120606-19:55:58.24156=42CLIENT17=1016=010=084

FIX_0-0@FIX.4.2:EXECUTOR->42CLIENT1 :: QF_EVENT: Sent ResendRequest FROM: 10 TO: 0

FIX_0-0@FIX.4.2:EXECUTOR->42CLIENT1 :: QF_IN: 8=FIX.4.29=10435=434=1043=Y49=42CLIENT152=20120606-19:55:58.24256=EXECUTOR122=20120606-19:55:58.24236=12123=Y10=067

FIX_0-0@FIX.4.2:EXECUTOR->42CLIENT1 :: QF_EVENT: ResendRequest for messages FROM: 10 TO: 10 has been satisfied.

FIX_0-0@FIX.4.2:EXECUTOR->42CLIENT1 :: QF_EVENT: Received SequenceReset FROM: 10 TO: 12

FIX_0-0@FIX.4.2:EXECUTOR->42CLIENT1 :: QF_IN: 8=FIX.4.29=6135=034=1249=42CLIENT152=20120606-19:56:28.23856=EXECUTOR10=213

FIX_0-0@FIX.4.2:EXECUTOR->42CLIENT1 :: QF_OUT: 8=FIX.4.29=6135=034=1049=EXECUTOR52=20120606-19:56:28.24056=42CLIENT110=204

FIX_0-0@FIX.4.2:EXECUTOR->42CLIENT1 :: QF_IN: 8=FIX.4.29=7035=234=1349=42CLIENT152=20120606-19:56:28.24156=EXECUTOR7=916=010=085

FIX_0-0@FIX.4.2:EXECUTOR->42CLIENT1 :: QF_EVENT: Received ResendRequest FROM: 9 TO: 0

FIX_0-0@FIX.4.2:EXECUTOR->42CLIENT1 :: QF_OUT: 8=FIX.4.29=10335=434=943=Y49=EXECUTOR52=20120606-19:56:28.24456=42CLIENT1122=20120606-19:56:28.24436=11123=Y10=025

FIX_0-0@FIX.4.2:EXECUTOR->42CLIENT1 :: QF_EVENT: Sent SequenceReset TO: 11

The problem appears to be that when receiving 35=2, the inbound sequence number is not incremented, resulting in the next inbound message having a MsgSeqNum that is too high. For example,

QF_IN: 8=FIX.4.29=6935=234=749=42CLIENT152=20120606-19:54:28.24156=EXECUTOR7=516=010=042

then

QF_EVENT: MsgSeqNum too high, expecting 7 but received 8

The same issue does not exist if either side have PersistMessages=Y, because the two sides are then able to work out and agree on the seq numbers.

Discussion