What is the correct behaviour for a fix (i.e. quickfix) client when we get resent messages interleaved with new/fresh messages?
I have a situation where we at logon detect a large number of missed messages, msgseqnum higher than expected.
The initiator issues a resend (open ended).
New fresh/unsolicited messages are received and are put to the queue.
The interesting part starts after the first missed fix message is received, (first resent message with 34 = BeginSeqNo)
When this happens our quickfixn initiator side goes into some mode and consider the resend complete (or something) and when we soon after a number of resent messages receive a new fresh/unsolicited message which is interleaved with the resend flow our initiator will send a new resend.
This sequence goes on and we will end up in a flood of concurrent resends and many duplicates of each every resent message filling the network.
Is it correct to interleave the live and resend feed by the acceptor ?
Should the quickfixn initiator send another resend in this case ?
( there is no 'resend complete' message so I can party understand the behaviour with sending the new resend but there is already a resend in progress.. )
Should the acceptor actually do concurrent and overlapping resends ?
Editing/adding to question since it got too long for a comment.
Our qfn is configured with default SendRedundantResendRequests (false) and it's also in effect with very many 'Not sending another'.
See e.g. the log:
20:53:35.087 : Received logon
20:53:35.087 : MsgSeqNum too high, expecting 2999869 but received 3002522
20:53:35.103 : Sent ResendRequest FROM: 2999869 TO: 0
20:53:35.103 : MsgSeqNum too high, expecting 2999869 but received 3002523
20:53:35.103 : Already sent ResendRequest FROM: 2999869 TO: 0. Not sending another.
[ very many 'already sent resendrequest' cut away ]
20:53:37.134 : Already sent ResendRequest FROM: 2999869 TO: 0. Not sending another.
20:53:37.134 : MsgSeqNum too high, expecting 2999869 but received 3004823
20:53:37.134 : Already sent ResendRequest FROM: 2999869 TO: 0. Not sending another.
20:53:37.134 : MsgSeqNum too high, expecting 2999869 but received 3004824
20:53:37.134 : Already sent ResendRequest FROM: 2999869 TO: 0. Not sending another.
20:53:37.134 : ResendRequest for messages FROM: 2999869 TO: 0 has been satisfied.
20:53:37.197 : MsgSeqNum too high, expecting 2999877 but received 3004825
20:53:37.197 : Sent ResendRequest FROM: 2999877 TO: 0
20:53:37.197 : ResendRequest for messages FROM: 2999877 TO: 0 has been satisfied.
20:53:37.197 : MsgSeqNum too high, expecting 2999893 but received 3004826
20:53:37.197 : Sent ResendRequest FROM: 2999893 TO: 0
20:53:37.212 : ResendRequest for messages FROM: 2999893 TO: 0 has been satisfied.
20:53:37.244 : Received SequenceReset FROM: 2999893 TO: 2999894
20:53:37.259 : MsgSeqNum too high, expecting 2999905 but received 3004827
20:53:37.259 : Sent ResendRequest FROM: 2999905 TO: 0
20:53:37.259 : ResendRequest for messages FROM: 2999905 TO: 0 has been satisfied.
20:53:37.275 : MsgSeqNum too high, expecting 2999919 but received 3004828
20:53:37.275 : Sent ResendRequest FROM: 2999919 TO: 0
20:53:37.275 : ResendRequest for messages FROM: 2999919 TO: 0 has been satisfied.
20:53:37.275 : MsgSeqNum too high, expecting 2999933 but received 3004829
20:53:37.275 : Sent ResendRequest FROM: 2999933 TO: 0
The event 'FROM: 2999869 TO: 0 has been satisfied' makes qfn think that the ongoing resend is done and on the next 'MsgSeqNum too high, expecting 2999877 but received 3004825' issues another resend although there is already a resend ongoing.
This continues and the example above gives multiple concurrent resends.
Should the client send another resend request before 3002521 ?
What happend here is that we get resent messages 2999869 - 2999876 but then we get 3004825 which (incorrectly?) triggers a new resend.