Available since FIXEdge 6.3.0.
In case huge resend requests it might takes long time to prepare messages as a reply on resend request. Actually FIX session is blocked during that period and doesn't send any real-time messages and even heartbeats. Sometimes (it depends on heartbeat interval and the volume of requested data) it can also lead FIX session to be considered lost by the counterparty.
Since FIXEdge 6.3.0 this problem has been addressed by means of two mechanisms:
- limiting volume of messages that can be sent as a reply on the each resend request,
- ignoring duplicate resend requests.
Use the following property in FIXEdge.properties to configure and limit volume of messages sent as a reply on resend request:
This parameter is optional. Valid values:
- '-1' - disabled (default value)
- '0' - do not resend real messages, reply with GapFill
- positive number - max number of messages
So if ResendMessagesLimit is set to 100 FIXEdge receives resend request for messages from 10 to 3 000 000 then FIXEdge answers with messages with sequence numbers 10 till 110 and and sends a heartbeat immediately with current outgoing sequence number.
After that counterparty detects a new gap and sends a new resend request for the range 110 - 3 000 000. And so on.
If ResendMessagesLimit property for the FIX session is set to 0 or to any positive number, then another mechanism for ignoring duplicate resend requests is automatically enabled.
FIXEdge considers the resend requests as duplicates if they have the same requested range: tags BeginSeqNo (7) and EndSeqNo (16), and have consequent sequence numbers (34).
So for handling huge resend requests it is recommended to set some reasonable value for the property ResendMessagesLimit. e.g.:
FixLayer.FixEngine.Session.Session_Name.ResendMessagesLimit = 1000
Note that the described behavior is a violation from the FIX standard. Ensure that the counterparty is ready for this.