[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/4a45ab15 - PLEASE DO NOT REPLY BY MAIL.]
I hit post before I finished what I wanted to say: The issue is that the resend request is purely a session layer protocol. So the resend may happen on restart if there is corruption of the persistence at the session layer. As one of the reponders pointed out. In such a situation should the application layer just ignore the message if it had already been processed. I think one of the other responders answered this question as well. Since we were the one's that sent the resend request we should possibly drop it, However the application layer does not know who originated the resend request, all it knows is that the message was a result of a resend. Thanks again for all the responses. Ramesh > 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 -~----------~----~----~----~------~----~------~--~---
