Re: [Quickfix-users] Session restarts
Brought to you by:
orenmnero
Menu
▾
▴
Re: [Quickfix-users] Session restarts
|
From: Brian E. <azz...@ya...> - 2006-04-04 21:57:42
|
Oren -
I have a fix that passes all unit tests. I'd like to ask you how you would prefer to see the fix implemented.
Essentially, I just try to figure out the "absolute" day that each timestamp's session week began.
I do this by:
1. Calculating the number of days since Jan 1, 1AD to the beginning of the year for each timestamp
2. Add the appropriate getYearDay() to each number of days value
3. Subtract the appropriate getWeekDay() from each number of days value
This gives us the "absolute" day for the Sunday that started each week. If those two values are the same, the two timestamps fall within the same week and, as we already know they're in a session and that there can only be one session per week (if there is a start and end day), they are in the same session.
This calculation is trivially simple, but I implemented the absolute day calculator as a simple function, which I doubt you'd prefer. I can perform the simple (but ugly) math within the isSameSession method, or create a private helper method (e.g., int getAbsoluteDay(int year, int dayOfYear)). Do you prefer one over the other, or just the existing getAbsoluteDay(int year, int dayOfYear) function?
- Brian Erst
p.s. The change is as follows (1.9.4 code branch - I obviously will check against 1.11.x). These are added to/replaced within SessionTime.cpp.
// Calculate the number of days since Jan 1, 1AD
int getAbsoluteDay(int year, int dayOfYear)
{
int numberOfLeaps = (year-1)/4 - (year-1)/100 + (year-1)/400;
return ((year-1)*365) + numberOfLeaps + dayOfYear;
}
// New version of the method fixes DST problems
bool SessionTime::isSameSession( const UtcTimeOnly& startTime,
const UtcTimeOnly& endTime,
int startDay,
int endDay,
const UtcTimeStamp& time1,
const UtcTimeStamp& time2 )
{ QF_STACK_PUSH(SessionTime::isSameSession)
if( !isSessionTime( startTime, endTime, startDay, endDay, time1 ) )
return false;
if( !isSessionTime( startTime, endTime, startDay, endDay, time2 ) )
return false;
// If the Sundays of each timestamp are the same day, we must be in the same session (there's only one session per week)
return getAbsoluteDay(time1.getYear(), time1.getYearDay()-time1.getWeekDay()) ==
getAbsoluteDay(time2.getYear(), time2.getYearDay()-time2.getWeekDay());
QF_STACK_POP
}
p.p.s. I added some tests (spanning a year - Dec 31, 06 and Jan 1,07 within a Sunday-Saturday session) as well as testing startDay and endDay = -1, and everything passed.
----- Original Message ----
From: Brian Erst <azz...@ya...>
To: qui...@li...
Sent: Tuesday, April 4, 2006 3:30:53 PM
Subject: Re: [Quickfix-users] Session restarts
QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX Support: http://www.quickfixengine.org/services.html
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
-------------------------------------------------------
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
|
