Re: [Quickfix-developers] messages lost during EndOfDay

[Oren M. <or...@qu...>]

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