[Quickfix-developers] Re: QuickFIX for Python
Brought to you by:
orenmnero
|
From: Oren M. <or...@qu...> - 2006-04-07 17:08:16
|
I checked in a fix that makes sure the SendingTime and OrigSendingTime will match for SequenceReset messages. The resend functionality is different because there the timestamps can and should be different, but for SequenceResets, the message is being sent for the first time. The only reason there is an OrigSendingTime in the message is that it must accompany and message containing a PossDup field. And the only reason it has a PossDup field is because any message sent as a result of a resend request must contain a PossDup field, even if the message was never sent before. So it is a bit of an anomoly. --oren On Apr 5, 2006, at 9:10 PM, Shawn Yarbrough wrote: > Hi, > > I saw what I think is a rare timing bug, I think located in > Session.cpp, in the "Session::generateSequenceReset" function. > > If the clock increments at exactly the *wrong* time, then the > SendingTime(52) in the Sequence Reset message can be 1 millisecond > off from the OrigSendingTime(122). The exchange I care about (CME) > rejects the message due to the 1 millisecond difference and the > session fails horribly. > > Or maybe I'm misinterpreting the evidence, see for yourself: > > > The exchange error I saw (thru an exchange report somewhere): > > We received a SequenceReset(4) message, but it had the > following errors: > Field OrigSendingTime: we expected '20060406-01:34:15.082', but > we received '20060406-01:34:15.081' > > > The relevant messages from the QuickFIX log: > > 8=FIX.4.2|9=76|35=2|49=CME|56=???|52=20060406-01:34:14|34=5| > 369=6|50=G|57=???|7=1|16=0|10=161| > > 8=FIX.4.2|9=113|35=4|34=1|43=Y|49=???|50=???| > 52=20060406-01:34:15.082|56=CME|57=G|122=20060406-01:34:15.081| > 142=3|36=3|123=Y|10=007| > > > I see similar code in the "Session::resend" function, but it > handles the timestamp correctly there. Maybe the code can be > copied into "Session::generateSequenceReset". The > insertOrigSendingTime() call needs to not default the second > parameter. That second parameter should be the timestamp taken > from SendingTime. > > > Shawn Yarbrough > Senior E-Trading Developer > Gelber Group, LLC > sya...@ge... > > > THE MESSAGES AND DOCUMENTS TRANSMITTED WITH THIS NOTICE CONTAIN > CONFIDENTIAL INFORMATION BELONGING TO THE SENDER. IF YOU ARE NOT > THE INTENDED RECIPIENT OF THIS INFORMATION, YOU ARE HEREBY NOTIFIED > THAT ANY DISCLOSURE, COPYING, DISTRIBUTION OR USE OF THE > INFORMATION IS STRICTLY PROHIBITED. IF YOU HAVE RECEIVED THIS > TRANSMISSION IN ERROR, PLEASE NOTIFY THE SENDER IMMEDIATELY. > |