Re: [Quickfix-users] Session restarts

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

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...>; qui...@li...
Sent: Tuesday, April 4, 2006 12:19:48 PM
Subject: Re: [Quickfix-users] Session restarts

   DIV {  MARGIN: 0px }    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.