|
4.0 Session
< Previous Next >
Re: Rejection Loop
SriPavan Thayaparan <>
25 Jun 2008 1:40AM ETEva,
There are two types of protocol rejection in FIX and a business rejection as well.
1. Session level reject (Type 3 I think).
2. Business Reject (Type J)
3. 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 :-
1. Sequence errors
2. Required field missing errors
3. 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
Re: Rejection Loop
SriPavan Thayaparan 25 Jun 2008 1:40AM ET
|
