Remote FIX counter-party did not reply on Resend Request. What should my FIX engine do?

, ,
1

Imported from previous forum

2

We have a peculiar situation when after a connection drop our FIX engine have detected a message gap in incoming messages and requested resend. The remote FIX engine never replied because it lost that message but keep sending us hear beats. The problem is the our engine does detect gap in the subsequent messages but does not do anything (besides printing warnings) because it already sent ResendRequest

I have search FIX 4.2 protocol an I was unable to find how the protocol treat such situation - it probably implementation dependent. What other FIX engine implementations do in such situations.

Thank you.

Len.

3

[ original email was from John Prewett - jprewett@lavatrading.com ]
> We have a peculiar situation when after a connection drop our FIX engine

have detected a message gap in incoming messages and requested resend.
The remote FIX engine never replied because it lost that message but
keep sending us hear beats. The problem is the our engine does detect
gap in the subsequent messages but does not do anything (besides
printing warnings) because it already sent ResendRequest

I have search FIX 4.2 protocol an I was unable to find how the protocol
treat such situation - it probably implementation dependent. What other
FIX engine implementations do in such situations.

Thank you.

Len.

Hi Len,

I don’t think the specification details exactly how to handle this case, so I will tell you what I do. If I haven’t received at least the first message that I requested from a resend request after a minimum of 1 heartbeat interval, I logout and disconnect.

I disapprove of repeating the resend request as you could be requesting a very large number of messages and, if the other end suddenly remembers your old resend request as well as the repeat(s), you could well have unleashed a flood of messages.

I have seen certain cases where the other end had “issues” whereby it did occasionally fail to process a resend request. Disconnecting will almost certainly force an automatic reconnect (on most FIX engines) and life begins anew. Hopefully the next time the other FIX engine won’t fail to process your resend request. If it does, you will probably end up in a slow disconnect/reconnect loop. At which point, you will certainly need the counterparty to address the problem with their FIX engine.

A last and not recommended resort is to disconnect and reset the sequence numbers to avoid your counterparty’s resend request problem. This has the highly undesirable side-effect of possibly losing important messages.

I hope this helps.

JohnP

4

John,

Thanks a lot for response. Your solution with disconnect looks very interesting and I will definitely consider that. Before your reply I was incline to modify behavior of our FIX engine to resend request again after, let’s say, few heartbeats, but as you have said I may suffer from to many of incoming messages.

Len.

We have a peculiar situation when after a connection drop our FIX
engine have detected a message gap in incoming messages and requested
resend. The remote FIX engine never replied because it lost that
message but keep sending us hear beats. The problem is the our engine
does detect gap in the subsequent messages but does not do anything
(besides printing warnings) because it already sent ResendRequest

I have search FIX 4.2 protocol an I was unable to find how the
protocol treat such situation - it probably implementation dependent.
What other FIX engine implementations do in such situations.

Thank you.

Len.

Hi Len,

I don’t think the specification details exactly how to handle this case,
so I will tell you what I do. If I haven’t received at least the first
message that I requested from a resend request after a minimum of 1
heartbeat interval, I logout and disconnect.

I disapprove of repeating the resend request as you could be requesting
a very large number of messages and, if the other end suddenly remembers
your old resend request as well as the repeat(s), you could well have
unleashed a flood of messages.

I have seen certain cases where the other end had “issues” whereby it
did occasionally fail to process a resend request. Disconnecting will
almost certainly force an automatic reconnect (on most FIX engines)
and life begins anew. Hopefully the next time the other FIX engine
won’t fail to process your resend request. If it does, you will
probably end up in a slow disconnect/reconnect loop. At which point,
you will certainly need the counterparty to address the problem with
their FIX engine.

A last and not recommended resort is to disconnect and reset the
sequence numbers to avoid your counterparty’s resend request problem.
This has the highly undesirable side-effect of possibly losing
important messages.

I hope this helps.

JohnP