Re: [Quickfix-users] Session restarts
Brought to you by:
orenmnero
Menu
▾
▴
Re: [Quickfix-users] Session restarts
|
From: Brian E. <azz...@ya...> - 2006-04-04 20:31:04
|
Oren -
That may be a good idea (I'm sure plenty of people will be happy to use local time), but I don't think it will fix this issue. The underlying problem is that the SessionTime code assumes that all days have 86,400 seconds, which they don't. ST-to-DST days have 82,800 and DST-to-ST days have 90,000.
I think the existing code is clever, but flawed. A much simpler approach would be to have the session time code figure out a start-of-session day of the year and an end-of-session day of the year. If the day-of-year of both timestamps fall within that range, they are in the same session. (There is other code to determine whether they are within the time-of-day range.)
I've got a fix in mind, but I need to test it first.
- Brian
----- Original Message ----
I think this comes down to the issue that we need to be able to
specify start and stop times in local time.
--oren
On Apr 4, 2006, at 2:59 PM, Brian Erst wrote:
> As an emergency fix, we're modifying our session to start on Monday
> for the remainder of the week (requiring us to bounce our
> application), which avoids the DST missing hour bug. I've tested
> this via the use case (changed startDay to 2 instead of 1) and it
> appears to work. Anyone with a multi-day session that started this
> last Sunday and just had a DST change should consider doing the same.
>
> I will think about a more permanent fix later (after more closely
> reviewing the 1.11.x branch).
>
> - Brian Erst
> Thynk Software, Inc.
>
> ----- Original Message ----
> From: Brian Erst <azz...@ya...>
> To: Oren Miller <or...@qu...>; quickfix-
> us...@li...
> Sent: Tuesday, April 4, 2006 1:55:22 PM
> Subject: Re: [Quickfix-users] Session restarts
>
> Oren -
>
> I added the following code to the
> SessionTimeTestCase::isSameSessionWithDay::onRun( SessionTime&
> object ) method:
>
> // Session: Sun 00:05:00 - Sat 23:45:00, test to see if Monday
> 4/3/2006-01:00:00 and Tuesday 4/4/2006-00:00:00 are in the same
> session
> startTime = UtcTimeOnly(0, 5, 0);
> endTime = UtcTimeOnly(23, 45, 0);
> startDay = 1;
> endDay = 7;
> time1 = UtcTimeStamp(0, 0, 0, 4, 4, 2006);
> time2 = UtcTimeStamp(1, 0, 0, 3, 4, 2006);
> assert( SessionTime::isSameSession(startTime, endTime, startDay,
> endDay, time1, time2) );
>
> The assertion fails. Looking into the isSameSession code, it fails
> on the following code:
>
> int time1Range = time1.getWeekDay() - startDay;
> int time2Range = time2.getWeekDay() - startDay;
>
> if( time1Range == 0 )
> {
> UtcTimeOnly timeOnly = UtcTimeOnly( time1);
> if( timeOnly < startTime )
> time1Range = 7;
> }
>
> if( time2Range == 0 )
> {
> UtcTimeOnly timeOnly = UtcTimeOnly( time2 );
> if( timeOnly < startTime )
> time2Range = 7;
> }
>
> time_t t1 = time1.getTimeT() - DateTime::SECONDS_PER_DAY *
> time1Range;
> time_t t2 = time2.getTimeT() - DateTime::SECONDS_PER_DAY *
> time2Range;
>
> tm tm1 = time_gmtime( &t1 );
> tm tm2 = time_gmtime( &t2 );
>
> return tm1.tm_year == tm2.tm_year
> && tm1.tm_yday == tm2.tm_yday;
>
> In this test case, after the calculations tm1.tm_yday = 90 and
> tm2.tm_yday = 91, so they aren't in the "same" session. I'm
> guessing that when the subtraction occurs, the "00:00:00" case is
> being pushed into Saturday due to the missing hour, causing a one
> day span. My quick perusal of the modified code in QF 1.11.1 looks
> like it won't fix this problem.
>
> I've got to puzzle out how to fix this...
>
> - Brian Erst
> Thynk Software, Inc.
>
> ----- Original Message ----
> From: Oren Miller <or...@qu...>
> To: Brian Erst <azz...@ya...>; quickfix-
> us...@li...
> Sent: Tuesday, April 4, 2006 12:19:48 PM
> Subject: Re: [Quickfix-users] Session restarts
>
> Brian,
>
> Have you tried adding these scenarios to the unit tests? Were the
> results normal?
>
> --oren
> ----- Original Message -----
> From: Brian Erst
> To: qui...@li...
> Sent: Tuesday, April 04, 2006 12:08 PM
> Subject: [Quickfix-users] Session restarts
>
> We're seeing some very odd session resets since the switch to DST.
>
> Using QuickFIX 1.9.4 (it's a production environment, so we're a few
> releases back), I've got the following settings:
>
> ConnectionType=acceptor
> StartDay=Sunday
> StartTime=00:05:00
> EndDay=Saturday
> EndTime=23:45:00
> MillisecondsInTimeStamp=Y
> ResetOnLogout=N
> ResetOnDisconnect=N
>
> At 2006/04/03-00:00:00 UMT (5am Chicago time -5 UMT), all our
> connections reset. Our sessions were completely reset - the socket
> was dropped ("Dropped connection"), the sequence numbers were reset
> and we had all sorts of problems reconnecting (our clients
> attempted to reconnect, but our sequence numbers were now back to
> "1" and the logon response (resend sequence) had too low of a
> sequence number, causing the other side to drop us). Just when our
> operations staff got everything back in sync, the same thing
> happened at 01:00:00 UMT.
>
> The session then stayed up all day until, you guessed it, 00:00:00
> UMT on the 4th. All sessions were dropped and reset, we struggled
> to get things back up and at 01:00:00, it happened again. Needless
> to say, I'm not the most popular man in the organization today.
>
> I've looked at the Session, SessionTime, SessionState and FileStore
> code to try to track what's going on. I suspect that for some
> unexplained reason we're triggering a session reset because
> checkSessionTime() in Session.h is returning false. My guess is
> that we're resetting twice because the first time, the "current"
> time is failing (00:00:00 UMT) and the second time the "session
> creation time" (inside the .session file) is "00:00:00". Upon the
> creation of the second session, the .session creation time is
> 01:00:00 and we're safe until the "real time" is 00:00:00.
>
> The problem is - I can't figure out why this is happening. I've
> gone thru the SessionTime code, running the code thru my head with
> the appropriate values and everything SEEMS okay, but obviously
> something is wrong.
>
> As far as I can tell, last night I should have called isSameSession
> (00:00:05, 23:45:00, 1, 7, 2006/04/04-00:00:00,
> 2006/04/03:01:00:00) - which should have returned "true" but seems
> to have returned "false". I can't figure out why - the code is a
> little overly complicated (I can tell there are some buggy parts of
> 1.9.4's session time code - which shouldn't be triggered with these
> values) but it looks OK with these values.
>
> Further data point - prior to DST switch, this all worked. We've
> been running the exact same code and configuration for months with
> no problems. The only reason I mention DST is the coincidence that
> it would have first been exercised Monday morning, the problem is
> time related and it's only happened since then (and consistently
> every night).
>
> Ideas or suggestions?
>
> - Brian Erst
> Thynk Software, Inc.
>
>
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Quickfix-users mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-users
|
