Infinite SequenceReset with PersistMessages=N
Brought to you by:
orenmnero
Menu
▾
▴
#91 Infinite SequenceReset with PersistMessages=N
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.
