Re: [Quickfix-developers] messages lost during EndOfDay
Brought to you by:
orenmnero
|
From: Oren M. <or...@qu...> - 2006-11-13 17:37:56
|
Wow, how timely. This is related to the discussion the John and I have been having. =20 You actually want behavior that both of us agreed was a bad idea. =20 You are saying that messages sent after session close on the previous =20= day should go out on the next session. I would argue that this is =20 would be very surprising behavior to most people and would result in =20 some very angry emails. This is the exact situation I was referring =20 to where someone is pumping out orders end of day and comes in late =20 on a couple that get sent after session close. No big deal, but I =20 bet they would be shocked to find those orders going out the next day =20= based on market data that is no longer relevant. This is why QuickFIX makes no assumptions about messages sent outside =20= of a session time. If the session does not exist, the message does =20 not go out. That leaves no question in anybody's mind and requires =20 no assumptions on the part of the engine as to intent. QuickFIX will =20= not attempt to send message sent outside of a session any more than a =20= tcp socket will try to send packets sent outside of a connection. That being said, there clearly is a bug here. But I would say that =20 the bug is that sendToTarget should be returning false in this scenario. Otherwise the behavior is as intended. Once the sendToTarget return =20 value is fixed, you can use that to determine which messages QuickFIX =20= has accepted and which it has not. You would then send them on the =20 next available session (when you receive your onLogon callback). --oren On Nov 13, 2006, at 10:29 AM, G=F6hring Alexander wrote: > Hello quickfix developers/users, > > With QuickFIX Version 1.12.4 I observe the following behavior using =20= > the c++ examples tradeclient and executor: > > The fix session utc start and end times on both sides are =20 > configured as follows: > StartTime=3D15:55:00 > EndTime=3D15:50:00 > > If a new order is entered using the tradeclient after the EndTime, =20 > e.g. at 15:52 utc, the FIX::Session::sendToTarget API call returns =20 > successfully and the tradeclient application prints the outgoing =20 > message. Due to the session time configuration, the message has not =20= > yet been sent from the tradeclient to the executor. The message =20 > resides in the tradeclient's message store, having a message =20 > sequence number of 1. > > As soon as the StartTime is reached again (15:55), the tradeclient =20 > application logs on to the executor, but the new order will not be =20 > sent. Reviewing the tradeclient's message store shows, that the =20 > message store has been cleaned up and does only contain the logon =20 > and subsequent heartbeat messages between the tradeclient and =20 > executor. > > This behavior causes messages that are sent between end and start =20 > time to be 'lost'. I expected the new order message to be sent as =20 > soon as the new FIX session has been established. > > - Is this behavior of QuickFIX correct or is it a bug ? > - If this behavior is intented, what additional steps / API calls =20 > are required to ensure, that messages sent between two FIX sessions =20= > (after end and before start time), get transmitted ? > > Regards, > alex goehring |