Imported from previous forum
Hello,
I had the following problem and don’t really know how it should be handled:
First I send an order which is rejected for any reason, for example “Unknown instrument”. My counterparty sends me an ExecutionReport with this information, but due to the unknown instrument the value in tag “Symbol” (55) is empty. On my side this leads to a Reject Message.
So far so good. But: The ExecutionReport has been received, but not really handled, so I don’t increment the incoming SequenceNumber. Due to this, my application sends a ResendRequest and the whole game starts again… The result is a never-ending loop with ResendRequest - ExecutionReport - Reject - SequenceReset …
In my opinion, the counterparty should react somehow to my Reject Message. Or at least doesn’t resend the faulty ExecutionReport.
Does anybody had the same problem before or any ideas how I should solve this?
The FIX 4.2 Specification tells only that “there should be some logic…” 
:
“Note: The receiving application should disregard any message that is garbled, cannot be parsed or
fails a data integrity check. Processing of the next valid FIX message will cause detection of a
sequence gap and a Resend Request will be generated. Logic should be included in the FIX engine to
recognize the possible infinite resend loop, which may be encountered in this situation.”
Thanks for any help or ideas!
Eva
[ original email was from Greg Orsini - greg.orsini@orcsoftware.com ]
Eva,
You should increment the next expected sequence number when rejecting an incoming message. You should not be sending the resend request in your scenario.
From the FIX 4.0 & 4.2 specs:
The reject message should be issued when a message is received which cannot be passed through to the application level. An example of when a reject may be appropriate would be the receipt of a message with invalid basic data (e.g. MsgType=&) which successfully passes de-encryption, CheckSum and BodyLength checks. (As a rule, messages should be forwarded to the trading application for business level rejections whenever possible.)
Rejected messages should be logged and the incoming sequence number incremented.
Regards, Greg.
Hello,
I had the following problem and don’t really know how it should
be handled:First I send an order which is rejected for any reason, for example
“Unknown instrument”. My counterparty sends me an ExecutionReport with
this information, but due to the unknown instrument the value in tag
“Symbol” (55) is empty. On my side this leads to a Reject Message.So far so good. But: The ExecutionReport has been received, but not
really handled, so I don’t increment the incoming SequenceNumber. Due to
this, my application sends a ResendRequest and the whole game starts
again… The result is a never-ending loop with ResendRequest -
ExecutionReport - Reject - SequenceReset …In my opinion, the counterparty should react somehow to my Reject
Message. Or at least doesn’t resend the faulty ExecutionReport.Does anybody had the same problem before or any ideas how I should
solve this?The FIX 4.2 Specification tells only that “there should be some
logic…”:
“Note: The receiving application should disregard any message that is
garbled, cannot be parsed or fails a data integrity check. Processing of
the next valid FIX message will cause detection of a sequence gap and a
Resend Request will be generated. Logic should be included in the FIX
engine to recognize the possible infinite resend loop, which may be
encountered in this situation.”Thanks for any help or ideas! Eva
Hello Greg,
indeed I I have to Sequence Numbers in my system: SeqNum_rcvd und SeqNum_done. Indeed the SeqNum_rcvd will be incremented also in case of rejection. But I’m not sure if I also shall increment the SeqNum_done - finally the message is not handled correctly.
So in fact it’s the question how to react correctly. To loop is wrong, sure. But is it more correct to just ignore and log the message that couldn’t be handled? Maybe this leads to some other unexpected effects…
Or does it make sense to close the connection in this case with an error?
Maybe I’m overestimating this case but maybe it’s worth to discuss it a little bit?
Bye Eva
Eva,
You should increment the next expected sequence number when rejecting
an incoming message. You should not be sending the resend request in
your scenario.From the FIX 4.0 & 4.2 specs:
The reject message should be issued when a message is received which
cannot be passed through to the application level. An example of when a
reject may be appropriate would be the receipt of a message with invalid
basic data (e.g. MsgType=&) which successfully passes de-encryption,
CheckSum and BodyLength checks. (As a rule, messages should be forwarded
to the trading application for business level rejections whenever
possible.)Rejected messages should be logged and the incoming sequence number
incremented.Regards, Greg.
Hello,
I had the following problem and don’t really know how it should be
handled:First I send an order which is rejected for any reason, for example
“Unknown instrument”. My counterparty sends me an ExecutionReport with
this information, but due to the unknown instrument the value in tag
“Symbol” (55) is empty. On my side this leads to a Reject Message.So far so good. But: The ExecutionReport has been received, but not
really handled, so I don’t increment the incoming SequenceNumber. Due
to this, my application sends a ResendRequest and the whole game
starts again… The result is a never-ending loop with ResendRequest -
ExecutionReport - Reject - SequenceReset …In my opinion, the counterparty should react somehow to my Reject
Message. Or at least doesn’t resend the faulty ExecutionReport.Does anybody had the same problem before or any ideas how I should
solve this?The FIX 4.2 Specification tells only that “there should be some
logic…”“Note: The receiving application should disregard any message that is
garbled, cannot be parsed or fails a data integrity check. Processing
of the next valid FIX message will cause detection of a sequence gap
and a Resend Request will be generated. Logic should be included in
the FIX engine to recognize the possible infinite resend loop, which
may be encountered in this situation.”Thanks for any help or ideas! Eva
Eva,
There are two types of protocol rejection in FIX and a business rejection as well.
- Session level reject (Type 3 I think).
- Business Reject (Type J)
- Execution Report - Exec Type = 8 (Type 8)
Now all these are rejects of one for or the other, but responding to these three is entirely different.
Session Level Reject :-
Any basic Session validation failure. It includes the following :-
- Sequence errors
- Required field missing errors
- Tag not defined errors
- For more info see session error codes*
ONLY THIS TYPE SHOULD NOT RESULT IN RECVD SEQ INCREMENT.
In your case the reject you offer is probably a Business Reject. Its an app layer reject in Fix. This will probably require incrementing the internal recvd sequence number do that the next expected is one added to the erroneous message.
Generally, in practice, a certified FIX Engine shouldn’t all of a sudden throw off session rejects in the midst of production. If so, something is seriously wrong and should be rectified perhaps manually. This is the practice we use.
Rgds,
Thaya.
Hello Greg,
indeed I I have to Sequence Numbers in my system: SeqNum_rcvd und
SeqNum_done. Indeed the SeqNum_rcvd will be incremented also in case of
rejection. But I’m not sure if I also shall increment the SeqNum_done -
finally the message is not handled correctly.So in fact it’s the question how to react correctly. To loop is wrong,
sure. But is it more correct to just ignore and log the message that
couldn’t be handled? Maybe this leads to some other unexpected
effects…Or does it make sense to close the connection in this case with an
error?Maybe I’m overestimating this case but maybe it’s worth to discuss it a
little bit?Bye Eva
Eva,
You should increment the next expected sequence number when rejecting
an incoming message. You should not be sending the resend request in
your scenario.From the FIX 4.0 & 4.2 specs:
The reject message should be issued when a message is received which
cannot be passed through to the application level. An example of when
a reject may be appropriate would be the receipt of a message with
invalid basic data (e.g. MsgType=&) which successfully passes de-
encryption, CheckSum and BodyLength checks. (As a rule, messages
should be forwarded to the trading application for business level
rejections whenever possible.)Rejected messages should be logged and the incoming sequence number
incremented.Regards, Greg.
Hello,
I had the following problem and don’t really know how it should be
handled:First I send an order which is rejected for any reason, for example
“Unknown instrument”. My counterparty sends me an ExecutionReport
with this information, but due to the unknown instrument the value
in tag “Symbol” (55) is empty. On my side this leads to a Reject
Message.So far so good. But: The ExecutionReport has been received, but not
really handled, so I don’t increment the incoming SequenceNumber.
Due to this, my application sends a ResendRequest and the whole game
starts again… The result is a never-ending loop with ResendRequest
- ExecutionReport - Reject - SequenceReset …
In my opinion, the counterparty should react somehow to my Reject
Message. Or at least doesn’t resend the faulty ExecutionReport.Does anybody had the same problem before or any ideas how I should
solve this?The FIX 4.2 Specification tells only that “there should be some
logic…”“Note: The receiving application should disregard any message that
is garbled, cannot be parsed or fails a data integrity check.
Processing of the next valid FIX message will cause detection of a
sequence gap and a Resend Request will be generated. Logic should be
included in the FIX engine to recognize the possible infinite resend
loop, which may be encountered in this situation.”Thanks for any help or ideas! Eva