[This message was posted by kofil ali of Aspect capital <[email protected]> to the "4.0 Session" discussion forum at http://fixprotocol.org/discuss/12. You can reply to it on-line at http://fixprotocol.org/discuss/read/e86e81e8 - PLEASE DO NOT REPLY BY MAIL.]
> Using FIX should guarantee that no messages are lost or re-ordered. > Putting an application between two streams of messages relies on the > application also offering that guarantee. IMHO, after an outage is over, you > have every right to expect that your broker sends you all the messages you > have missed and in the appropriate sequence. > > .... However, anything can and will happen..... > > If you want to make your application robust, it should not only handle what > is supposed to happen but also gracefully handle unexpected events too. Now > that's very easy to say and often much more difficult to achieve. > > If you can interpret the messages received in an unambiguous manner, even > though they may violate the state model, I would declare that life is fairly > good. > > In your specific case, the fact that you have received a fill on the > replacement version, clearly indicates the replacement version must have been > accepted. At that point, I would immediately infer an ExecReport(replaced) > "replace-ack" and process the fill. I would probably also raise an alert to > indicate that the ExecReport(replaced) was missing as this is an unusual > situation. I also check LeavesQty and CumQty and ensure that they agree with > your understanding of where the order should be at this point. > > I hope this helps. > > JohnP > > > Hi Guys, > > > > I wonder if someone can help me here. > > Yesterday I had a problem where we sent a cancel\replace for a price to our > > broker, we did not recive an ACK back from the broker to say that they have > > recived the price replace message, instead four minutes later we recive a > > fill back for that order with the new price. > > I am in discussion with the broker to find out why we did not recive the > > ACK and why we had a four minute delay in the getting the fill back. > > > > Initial conversations seem to suggest that the broker might have suffered a > > disconnection with the exchange after we sent the cancel replace. However > > once the connection is restored I expect the messages to come back in a > > sequence, i.e, ack for the replace first and then the fill execution > > report. > > > > Any one come across this behaviour before? > > > > Many Thanks > > > > Kofil Hi John, Thanks for your reponse. The broker has come back and said that becuase they disconnected from the (briefly) exchange this caused the cancel\replace not to be accepted on the exchange side. Which is udenrstandable, but surely the broker should be able to handle the message better and relay it on to us? Have you coem across this problem before? [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.
