[This message was posted by Nicholas Tuttle of LineData Services <[email protected]> to the "Certification" discussion forum at http://fixprotocol.org/discuss/9. You can reply to it on-line at http://fixprotocol.org/discuss/read/9c22b57d - PLEASE DO NOT REPLY BY MAIL.]
I semi-disagree. If POSSDUPFLAG=Y is included on the message, then the message SHOULD carry the same seq num as the original message. The first part of the question makes sense: Resend request is sent > orders are resent with PossDupFlag=Y (presumably with the same seq nums as originally, though this wasn't specified). Technically speaking, re-acking with PossRESEND=Y should be ok so long as the resent acks carry NEW seq nums. However, best practice would be to only ack the order messages which truly weren't originally received (ie, your side should know if they've already sent an ack and should avoid PossResend if possible). I say this because, in my experience, PossResend isn't typically handled as gracefully as PossDupFlag. With PossDupFlag=Y your engine can say "ok, have I received this seq num before this session? If yes - ignore. If no - process message" With PossResend the FIX engine has to say "ok, how do I determine if I've received this before?" and have more complicated logic in place; ie, look for dupe ClOrdID or ExecID. > There are two questions in your posting: > 1. How should we respond? > 2. Should this be happening at all? > > I'm going to answer this in reverse order. > > 3. Should this be happening at all? No. Something is going wrong with > your FIX engine or its interface to your application, or both. If > you have already received and processed a message with a certain > MsgSeqNum and the FIX engine gives it to you again (same MsgSeqNum), > something is going very badly wrong. The application should only be > processing incoming messages with an ever-increasing MsgSeqNum. The > situation you describe should not be happening. > > 4. How do we respond? Due to the fact that the situation should not > be happening, I would terminate the FIX session, alert your > support staff and delegate the problems away from your automated > system to humans. > > Good luck. Sounds nasty. > > JohnP [You can unsubscribe from this discussion group by sending a message to mailto:[email protected]] --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Financial Information eXchange" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/fix-protocol?hl=en -~----------~----~----~----~------~----~------~--~---
