Imported from previous forum
Hi,
My question is about Resend Request message. I have trouble with counterparty(accepter side. also, our engine is
initiator side.)
When our fix engine sends Resend Request, counterparty does not retransmit messages, it just sends Sequence Reset message with GapFillFlag=Y. By then, our fix engine could not fill the gap and it could not send any messages.
When I declared this situation to counterparty, they replied me that their fix engine doesn’t persist some messages in db(performance issues!!), so it could not retransmit messages.
Is there any solution to recover this problem? (p.s. project is in development phase)
Thanks in advance.
Hi Haldun,
as per FIX specs, a Sequence Reset is an allowed response to a Resend Request; if a counterparty has not applicative messages to resend, it can force a sequence reset with gapfillflag=Y avoiding a massive session messages resend…
quote FIX 4.4 specs VOL2 with errata
“Sequence Reset (Gap Fill)
[…]Gap Fill mode is used in response to a Resend Request when one or more messages must be skipped over for the
following reasons:
• During normal resend processing, the sending application may choose not to send a message (e.g. an aged
order).
• During normal resend processing, a number of administrative messages are skipped and not resent (such as
Heart Beats, Test Requests).
Gap Fill mode is indicated by GapFillFlag (tag 123) field = “Y”.
[…]”
Hope that this helps,
Lanfranco
Hi,
My question is about Resend Request message. I have trouble with counterparty(accepter side. also, our engine is
initiator side.)
When our fix engine sends Resend Request, counterparty does not retransmit messages, it just sends Sequence Reset message with GapFillFlag=Y. By then, our fix engine could not fill the gap and it could not send any messages.
When I declared this situation to counterparty, they replied me that their fix engine doesn’t persist some messages in db(performance issues!!), so it could not retransmit messages.
Is there any solution to recover this problem? (p.s. project is in development phase)
Thanks in advance.
But what about the replies of collateral assignment or registration instructions messages?(these are not aged orders and also we do not expect administrative messages)
For example, we send 1000 collateral assignment messages to the counterparty and we expect 1000 collateral responses. if our engine doesn’t parse(or receive) a collateral response message(say 535th message) then sends resend request for this message. but they could not respond it, they just send a sequence reset(because they do not persist collateral responses in their db), so our engine could not receive following collateral responses.
Is it an architecture problem of our counterparty?
Any solution?
Hi Haldun,
as per FIX specs, a Sequence Reset is an allowed response to a Resend Request; if a counterparty has not applicative messages to resend, it can force a sequence reset with gapfillflag=Y avoiding a massive session messages resend…quote FIX 4.4 specs VOL2 with errata
“Sequence Reset (Gap Fill)
[…]Gap Fill mode is used in response to a Resend Request when one or more messages must be skipped over for the
following reasons:
• During normal resend processing, the sending application may choose not to send a message (e.g. an aged
order).
• During normal resend processing, a number of administrative messages are skipped and not resent (such as
Heart Beats, Test Requests).
Gap Fill mode is indicated by GapFillFlag (tag 123) field = “Y”.
[…]”Hope that this helps,
LanfrancoHi,
My question is about Resend Request message. I have trouble with counterparty(accepter side. also, our engine is
initiator side.)
When our fix engine sends Resend Request, counterparty does not retransmit messages, it just sends Sequence Reset message with GapFillFlag=Y. By then, our fix engine could not fill the gap and it could not send any messages.
When I declared this situation to counterparty, they replied me that their fix engine doesn’t persist some messages in db(performance issues!!), so it could not retransmit messages.
Is there any solution to recover this problem? (p.s. project is in development phase)
Thanks in advance.
Your solution lies in a “bilateral agreement” which needs to be driven by the business requirements (and common sense). FIX provides gap fills for good reason but these may not make sense in your situation. It sounds like they do not. If you need confirmation for collateral assignments then your counterparty should make sure that you get them. Otherwise you have no choice but to solve it on the application layer by re-sending the assignments because the previous ones were not confirmed. Your session layer only cares about getting “all” messages which includes gap fills for those that are not actually resent. Your application layer then has to deal with the consequences of not getting relevant business content.
Regards,
Hanno.
But what about the replies of collateral assignment or registration instructions messages?(these are not aged orders and also we do not expect administrative messages)
For example, we send 1000 collateral assignment messages to the counterparty and we expect 1000 collateral responses. if our engine doesn’t parse(or receive) a collateral response message(say 535th message) then sends resend request for this message. but they could not respond it, they just send a sequence reset(because they do not persist collateral responses in their db), so our engine could not receive following collateral responses.
Is it an architecture problem of our counterparty?
Any solution?Hi Haldun,
as per FIX specs, a Sequence Reset is an allowed response to a Resend Request; if a counterparty has not applicative messages to resend, it can force a sequence reset with gapfillflag=Y avoiding a massive session messages resend…quote FIX 4.4 specs VOL2 with errata
“Sequence Reset (Gap Fill)
[…]Gap Fill mode is used in response to a Resend Request when one or more messages must be skipped over for the
following reasons:
• During normal resend processing, the sending application may choose not to send a message (e.g. an aged
order).
• During normal resend processing, a number of administrative messages are skipped and not resent (such as
Heart Beats, Test Requests).
Gap Fill mode is indicated by GapFillFlag (tag 123) field = “Y”.
[…]”Hope that this helps,
LanfrancoHi,
My question is about Resend Request message. I have trouble with counterparty(accepter side. also, our engine is
initiator side.)
When our fix engine sends Resend Request, counterparty does not retransmit messages, it just sends Sequence Reset message with GapFillFlag=Y. By then, our fix engine could not fill the gap and it could not send any messages.
When I declared this situation to counterparty, they replied me that their fix engine doesn’t persist some messages in db(performance issues!!), so it could not retransmit messages.
Is there any solution to recover this problem? (p.s. project is in development phase)
Thanks in advance.