[This message was posted by Ramesh Kadambi of Pipeline Trading <[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/fb7427b2 - PLEASE DO NOT REPLY BY MAIL.]
Hi, Thank you all for your responses. I see the contradiction in the test. The issue is that the sequence numbers are being manually changed to test the resend logic. I understand the complications involved in resending executions on orders already processed. I wanted to know if there was a standard way to handle this. Regards, Ramesh > Hi Ramesh, > > Your scenario implies that your system already generated Execution > Reports for the order messages in question. In such a scenario, you can > assume that the previously generated Execution Reports were received and > processed by the remote client. > > You should only need to resend Execution Reports if the client requests > retransmission. > > Your scenario seems a little unusual, though, because on the one hand > you state that the messages were missed, but on the other hand you state > that the messages had been handled. > > Therefore this implies (in your scenario) your application had a > failure which included the failure to store the inbound messages and, > upon restart, your application thinks there is a message gap when > there was none. > > Cheers, > > Dennis > > > Hi All, > > > > We are working on certification for a client and we have an issue with > > the way possdup flag is being handled. When we send a resend request > > to our client, the client plays back all the orders as expected. > > However, we resend acks on orders that we have already processed with > > a PossResend Flag set to "Y". > > > > The protocol specification seems to be silent about how it should be > > handled i.e. if the orders have already been processed should an ack > > be resent or the message just be dropped. > > > > The fact that we requested a resend request implies that our fix > > session does not believe that these messages were ever recieved. The > > fix session passes it on the application which then sends an ack back. > > Is this acceptable behaviour from our fix engine? > > > > Regards, Ramesh [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 -~----------~----~----~----~------~----~------~--~---
