Imported from previous forum
What should the initiator of a ResendRequest do if the requested message or messages are never received (assuming the initiator of the ResendRequest is still receiving heartbeats). This might occur if the original message was disregarded, and the flawed message was resent in response to the ResendRequest. This exact scenario is mentioned in a note in the description of reject messages in the 4.1 specifications (e.g. Page 16 of FIX 4.1 Session Only with Errata 19990630). No suggestions were made of possible corrective action. In this specific scenario, the problem is that no sequence number is recovered from the disregarded message.
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> What should the initiator of a ResendRequest do if the requested message or messages are never received (assuming the initiator of the ResendRequest is still receiving heartbeats). This might occur if the original message was disregarded, and the flawed message was resent in response to the ResendRequest. This exact scenario is mentioned in a note in the description of reject messages in the 4.1 specifications (e.g. Page 16 of FIX 4.1 Session Only with Errata 19990630). No suggestions were made of possible corrective action. In this specific scenario, the problem is that no sequence number is recovered from the disregarded message.
So what’s happening is that you’re receiving a specific message without a sequence number, ignoring it, getting the next message, declining to process it but sending a Resend Request, repeat ad nauseum? If so, you’re doing the right thing, and there’s no easy way out.
Some mechanism might allow you to realize the connection is dead and drop it; heartbeat interval may be a possibility, but I believe that people generally implement their inactivity counter by resetting it after each valid message is received, regardless of whether it is in sequence. This wouldn’t detect the condition you’re seeing. Some implementations attempt to detect infinite resend request loops by killing the connection after N consecutive Resend Requests are either sent or received; this may work in your case.
But even if you realize the connection is having issues and drop it, connecting again will just get you into the same problem after the Logons are exchanged, assuming the other party keeps resending the offending message without a sequence number.
In this case, I would think the main ways out would be to have the other party send a SeqReset to break out of the loop and step over the offending message, or to set your own inbound expected sequence number beyond the offending message. Both of these methods are probably best handled by manual intervention.