Details
Description
When QF/J receives a ResendRequest it does not check for the MsgSeqNum of the ResendRequest. Depending on the MsgSeqNum on the ResendRequest it does the following (no PossDup flag was set):
- MsgSeqNum on ResendRequest too low: QF/J performs the normal resending or SequenceReset, incoming sequence number is not altered
- MsgSeqNum on ResendRequest correct: QF/J performs the normal resending or SequenceReset, incoming sequence number is incremented
- MsgSeqNum on ResendRequest too high: QF/J performs the normal resending or SequenceReset, incoming sequence number is not altered
According to the spec (e.g. http://fixprotocol.org/documents/3070/FIX_Transport_1.1.pdf on pages 12 and 13) the behaviour should be as follows:
- MsgSeqNum too low: terminate the connection
- MsgSeqNum too high: perform the normal resending or SequenceReset, afterwards send a ResendRequest of your own to fill the gap
Attachments
Issue Links
- duplicates
-
QFJ-673 QFJ sequence problem following inbound SequenceReset - a previously received ResendRequest not "queued"?
- Closed