Re: [Quickfix-developers] messages lost during EndOfDay

[Brian E. <azz...@ya...>]

Oren -=0A=0AGiven that the subject seems to a popular one, perhaps QF confi=
guration should be extended to add a "LoginStartTime" and "LoginEndTime". T=
hese would default to the Start/EndTimes of the session, but if populated, =
would allow users to spool orders prior to the start of trading. I know a l=
ot of users have standard sets of orders that are submitted at the start of=
 each day, and others that have order management systems that are live prio=
r to trading that allow users to submit orders that will be sent to the exc=
hange as soon as the trading session begin.=0A=0AIn this scenario, "session=
" start and end times would define the period where QF accepts orders, and =
"login" start and end times would define the period where the opposite side=
 will accept orders. Orders outside the "session" times would still be reje=
cted/dropped.=0A=0AIn regards the possible bug, in previous releases overla=
pping session times (start time is "after" end time) has caused problems, e=
specially on weekly sessions. I used to have a session defined from Sunday =
at 16:30 to Sunday at 16:25 (essentially resetting the session once a week =
on Sunday afternoon) and it caused no end of problems, but this was using Q=
F 1.9.2. I know I, and others, have made patches to the SessionTime objects=
 since and these may have fixed that problem. But we modified our sessions =
to reset around midnight on Sunday (session starts Sunday at 0:05 and ends =
Saturday at 23:55), so I'm not sure if it ever got resolved.=0A=0A- Brian=
=0A=0A----- Original Message ----=0AFrom: Oren Miller <oren@quickfixengine.=
org>=0ATo: G=F6hring Alexander <ale...@el...>=0ACc: quickfi=
x-d...@li...=0ASent: Monday, November 13, 2006 11:33:=
09 AM=0ASubject: Re: [Quickfix-developers] messages lost during EndOfDay=0A=
=0AQuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/=
index.html=0AQuickFIX Support: http://www.quickfixengine.org/services.html=
=0A=0A=0AWow,  how timely.=0A=0AThis is related to the discussion the John =
and I have been having.  You actually want behavior that both of us agreed =
was a bad idea.  You are saying that messages sent after session close on t=
he previous day should go out on the next session.  I would argue that this=
 is would be very surprising behavior to most people and would result in so=
me very angry emails.  This is the exact situation I was referring to where=
 someone is pumping out orders end of day and comes in late on a couple tha=
t get sent after session close.  No big deal, but I bet they would be shock=
ed to find those orders going out the next day based on market data that is=
 no longer relevant.=0A=0A=0AThis is why QuickFIX makes no assumptions abou=
t messages sent outside of a session time.  If the session does not exist, =
the message does not go out.  That leaves no question in anybody's mind and=
 requires no assumptions on the part of the engine as to intent.  QuickFIX =
will not attempt to send message sent outside of a session any more than a =
tcp socket will try to send packets sent outside of a connection.=0A=0A=0AT=
hat being said, there clearly is a bug here.  But I would say that the bug =
is that sendToTarget should be returning false in this scenario.=0A=0A=0AOt=
herwise the behavior is as intended.  Once the sendToTarget return value is=
 fixed, you can use that to determine which messages QuickFIX has accepted =
and which it has not.  You would then send them on the next available sessi=
on (when you receive your onLogon callback).=0A=0A=0A--oren=0A=0AOn Nov 13,=
 2006, at 10:29 AM, G=F6hring Alexander wrote:=0AHello quickfix developers/=
users, =0AWith QuickFIX Version 1.12.4 I observe the following behavior usi=
ng the c++ examples tradeclient and executor: =0AThe fix session utc start =
and end times on both sides are configured as follows: =0AStartTime=3D15:55=
:00 =0AEndTime=3D15:50:00 =0AIf a new order is entered using the tradeclien=
t after the EndTime, e.g. at 15:52 utc, the FIX::Session::sendToTarget API =
call returns successfully and the tradeclient application prints the outgoi=
ng message. Due to the session time configuration, the message has not yet =
been sent from the tradeclient to the executor. The message resides in the =
tradeclient's message store, having a message sequence number of 1.=0AAs so=
on as the StartTime is reached again (15:55), the tradeclient application l=
ogs on to the executor, but the new order will not be sent. Reviewing the t=
radeclient's message store shows, that the message store has been cleaned u=
p and does only contain the logon and subsequent heartbeat messages between=
 the tradeclient and executor.=0AThis behavior causes messages that are sen=
t between end and start time to be 'lost'. I expected the new order message=
 to be sent as soon as the new FIX session has been established.=0A- Is thi=
s behavior of QuickFIX correct or is it a bug ? =0A- If this behavior is in=
tented, what additional steps / API calls are required to ensure, that mess=
ages sent between two FIX sessions (after end and before start time), get t=
ransmitted ?=0ARegards, =0A alex goehring=0A=0A=0A=0A----------------------=
---------------------------------------------------=0AUsing Tomcat but need=
 to do more? Need to support web services, security?=0AGet stuff done quick=
ly with pre-integrated technology to make your job easier=0ADownload IBM We=
bSphere Application Server v.1.0.1 based on Apache Geronimo=0Ahttp://sel.as=
-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D121642=0A_____=
__________________________________________=0AQuickfix-developers mailing li=
st=...@li...=0Ahttps://lists.sourceforge.=
net/lists/listinfo/quickfix-developers=0A=0A=0A=0A