quickfix-users — QuickFIX user support

Re: [Quickfix-users] Some questions about restarting a quickfix server

[Joerg T. <Joe...@ma...>]

Hi Staffan,

> I've recently been working a bit on a FIX acceptor for order handling
> using QuickFIX.  I'm using quickfixj, and have managed to get the
> connection up and the initiators seem happy with the setup.  That is,
> they can send orders and execution reports are sent back from my accept=
or.
>=20
> This is all still in the testing stage, however, and I was wondering
> about what to do whenever a connection is reconnected after a
> disconnect, and how to handle a restart of the server.  How much of
> gap filling and resending is handled by the quickfix engine itself?
> What do I have to do?  I realize the answer might be too complex for a
> short mail reply, but I've not been able to find much documentation
> either.  Any pointers?

All the session level gap fill/resend processing is done for you by the Q=
uickFIX engine.

But there are some fine points where you can influence the process:

Look at this scenario: You are sending an order to the exchange, but the =
connection breaks=20
down. QuickFIX takes care of your NewOrderSingle and will resend it as so=
on as the=20
connection is up again and the other side requested it as part of a Resen=
dRequest.

BUT: This may take a while and your order would be sent 10 mins too late.

Before sending the NewOrderSingle again, QF will pass it through the toAp=
p() callback.
Here you can check for the PossDup flag and if it is true, you can retrie=
ve the=20
OrigSendingTime, at which the order has been sent the first time. If the =
difference=20
between SendingTime (now) and OrigSendingTime is too large, you can throw=
 a DoNotSend=20
exception and QF will gap fill the message instead of sending the outdate=
d order.

> When the server is restarted, maybe after a crash, one way to find out
> if there are any orders whose status is not known by the client is to
> read the message log.  Is there any way to do that while using the
> quickfix engine's message parsing functions?

If the QF sendToTarget() method returns, the QF engine will make sure tha=
t the message=20
arrives at the client end after a crash or disconnection. So you just hav=
e to record which=20
of your order status related message you have already sent to QF and star=
t at this point.

If you are unsure whether you have already sent some application level me=
ssages to the=20
other side, you may flag messages with the PossResend flag which indicate=
s that the same=20
business information (e.g. a Fill) may have sent before to the other side=
 in another=20
message (different MsgSeqNo). Please do not confuse this with PossDup (it=
 relates to the=20
_same_ MsgSeqNo and is handled by the FIX engine).

Cheers, J=F6rg

--=20
Joerg Thoennes
                                http://macd.com
Tel.: +49 (0)241 44597-24      Macdonald Associates GmbH
Fax : +49 (0)241 44597-10      Lothringer Str. 52, D-52070 Aachen

[Quickfix-users] Some questions about restarting a quickfix server

[Staffan U. <sta...@mu...>]

Hi all,

I've recently been working a bit on a FIX acceptor for order handling
using QuickFIX.  I'm using quickfixj, and have managed to get the
connection up and the initiators seem happy with the setup.  That is,
they can send orders and execution reports are sent back from my acceptor.

This is all still in the testing stage, however, and I was wondering
about what to do whenever a connection is reconnected after a
disconnect, and how to handle a restart of the server.  How much of
gap filling and resending is handled by the quickfix engine itself?
What do I have to do?  I realize the answer might be too complex for a
short mail reply, but I've not been able to find much documentation
either.  Any pointers?

When the server is restarted, maybe after a crash, one way to find out
if there are any orders whose status is not known by the client is to
read the message log.  Is there any way to do that while using the
quickfix engine's message parsing functions?

Staffan

[Quickfix-users] Some questions about restarting a quickfix server

[Staffan U. <st...@ul...>]

Hi all,

I've recently been working a bit on a FIX acceptor for order handling
using QuickFIX.  I'm using quickfixj, and have managed to get the
connection up and the initiators seem happy with the setup.  That is,
they can send orders and execution reports are sent back from my acceptor.

This is all still in the testing stage, however, and I was wondering
about what to do whenever a connection is reconnected after a
disconnect, and how to handle a restart of the server.  How much of
gap filling and resending is handled by the quickfix engine itself?
What do I have to do?  I realize the answer might be too complex for a
short mail reply, but I've not been able to find much documentation
either.  Any pointers?

When the server is restarted, maybe after a crash, one way to find out
if there are any orders whose status is not known by the client is to
read the message log.  Is there any way to do that while using the
quickfix engine's message parsing functions?

Staffan

Re: [Quickfix-users] Session restarts

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

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

Re: [Quickfix-users] Session restarts

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

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

Re: [Quickfix-users] Session restarts

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

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.
>
>

Re: [Quickfix-users] Session restarts

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

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

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

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.

Re: [Quickfix-users] Session restarts

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

Brian,

Have you tried adding these scenarios to the unit tests?  Were the =
results normal?

--oren
  ----- Original Message -----=20
  From: Brian Erst=20
  To: qui...@li...=20
  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=3Dacceptor
  StartDay=3DSunday
  StartTime=3D00:05:00
  EndDay=3DSaturday
  EndTime=3D23:45:00
  MillisecondsInTimeStamp=3DY
  ResetOnLogout=3DN
  ResetOnDisconnect=3DN

  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.

[Quickfix-users] Session restarts

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

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.

[Quickfix-users] Re: [Quickfix-developers] QuickFixJ: Problem with message length calculation when the recei ved message contains a set of field/values pairs in the raw data field wh ich is tag '96'

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

Faraz,

I assume you are trying to connect to the NYSE Hybrid system.  We had to =
make some modifications to QuickFIX in order to work with this system.  =
Most of these changes have been checked in to the C++ source tree, but =
I'm not sure they all made it into QuickFIX/J.  So just a warning you =
may run into a couple issues besides this, but we are aware of what they =
are and can work to move the updates into QuickFIX/J.  If you have any =
specific questions about getting QuickFIX to work with cannonical =
messages, feel free to ask as we have worked with it extensively.

This looks like it may be a bug in how QuickFIX/J is handling data =
fields.  It is supposed to look at field 95 and put all the data into a =
single field while ignoring any special characters.  Steve, are data =
fields currently supported by QuickFIX/J?

--oren
  ----- Original Message -----=20
  From: Parhami, Faraz=20
  To: qui...@li... ; =
'qui...@li...'=20
  Sent: Monday, April 03, 2006 3:58 PM
  Subject: [Quickfix-developers] QuickFixJ: Problem with message length =
calculation when the recei ved message contains a set of field/values =
pairs in the raw data field wh ich is tag '96'


  Using QuickFixJ engine, in the following example, the engine does not =
know that field '96' contains a set of name value pairs (in this case =
starting with '10001' and ending with '11277'.=20
  I looked at the code and 'calculateLength' method of the =
'FieldMap.java' class thinks that '96=3D10001=3DCanonical.1.00^A' is one =
field. So it does not count the terminating SOH at close to the end of =
message (colored in bold red). Is this a bug?
  Right now, the engine thinks the length size is one less than =
expected:

  =
8=3DFIX.4.2^A9=3D01158^A35=3DU6^A34=3D4^A49=3DSAGW^A56=3DN03L43^A52=3D200=
60403-20:25:11.630^A95=3D1092^A
  =
96=3D10001=3DCanonical.1.00^A10002=3D001058^A25001=3D01^A10003=3DSAPI_ADM=
RESP^A10004=3DSUBSCRIBE_RESP^A10009=3D705^A10012=3D01^A
  =
10005=3DSPGW^A10006=3DSAPI^A10007=3D0^A10010=3D16:25:11.537^A10045=3DSDQA=
DL:01:/SDB/ENT/@/@/STKSDLL:7^A10955=3DY^A10963=3D043^A
  =
10961=3D03^A11285=3DN^A11339=3D823,980^A10919=3DN^A11111=3D86795696^A1089=
8=3D043^A10920=3D~^A10938=3DN^A11340=3D5-  9.99^A11343=3D0.20^A
  11344=3D~^A11341=3D~^A11342=3D0.15^A11345=3D10- =
14.99^A11348=3D0.25^A11349=3D~^A11346=3D~^A11347=3D0.15^A11350=3D15- =
19.99^A
  =
11353=3D0.30^A11354=3D~^A11351=3D~^A11352=3D0.20^A11338=3D23SEP05^A10981=3D=
0^A10485=3DN^A10761=3D0^A11220=3D~^A11224=3DN^A
  =
10808=3DN^A10921=3D~^A10960=3DN^A10957=3DN^A11329=3DN^A11286=3D0^A11214=3D=
USA^A10917=3DY^A11288=3D0^A10906=3DN^A10737=3D0.01^A10956=3D~^A
  =
10967=3D~^A10965=3D~^A10809=3D0^A10762=3DN^A10763=3DN^A10712=3D1^A10905=3D=
09:30:00^A10918=3DYA0101^A10951=3DY^A10469=3D1^A10949=3D1^A
  =
10487=3DQ^A10950=3DY^A10899=3DN^A10380=3DN^A10696=3D03^A11082=3D18.41^A10=
217=3D12^A10954=3DN^A10708=3DE^A10958=3DN^A11213=3DUS ^A
  =
11334=3DN^A11332=3DN^A11331=3DN^A11330=3DN^A11335=3DN^A11333=3DN^A10767=3D=
3^A10974=3D~^A10980=3DAIRTRAN HOLDINGS                ^A
  =
11289=3DN^A10912=3D4^A10915=3D0501^A10914=3D0501^A10975=3DN^A10913=3DSLK^=
A10698=3D055^A10666=3DAAI^A10903=3DS^A11328=3DN^A10624=3DL^A
  =
11287=3D0^A10699=3D0^A10962=3DL^A11227=3DSUB1^A11229=3D5^A11228=3D1^A1123=
6=3D16:24:41.521^A11277=3D16:25:11.630^A^A10=3D141^A

  30226 [SocketIoProcessor] ERROR =
quickfix.mina.initiator.InitiatorProtocolHandler  - Invalid message: =
Actual body length=3D1157, Expected body length=3D1158

[Quickfix-users] QuickFixJ: Problem with message length calculation when the recei ved message contains a set of field/values pairs in the raw data field wh ich is tag '96'

[Parhami, F. <Far...@gs...>]

Using QuickFixJ engine, in the following example, the engine does not know
that field '96' contains a set of name value pairs (in this case starting
with '10001' and ending with '11277'. 
I looked at the code and 'calculateLength' method of the 'FieldMap.java'
class thinks that '96=10001=Canonical.1.00^A' is one field. So it does not
count the terminating SOH at close to the end of message (colored in bold
red). Is this a bug?
Right now, the engine thinks the length size is one less than expected:
 
8=FIX.4.2^A9=01158^A35=U6^A34=4^A49=SAGW^A56=N03L43^A52=20060403-20:25:11.63
0^A95=1092^A
96=10001=Canonical.1.00^A10002=001058^A25001=01^A10003=SAPI_ADMRESP^A10004=S
UBSCRIBE_RESP^A10009=705^A10012=01^A
10005=SPGW^A10006=SAPI^A10007=0^A10010=16:25:11.537^A10045=SDQADL:01:/SDB/EN
T/@/@/STKSDLL:7^A10955=Y^A10963=043^A
10961=03^A11285=N^A11339=823,980^A10919=N^A11111=86795696^A10898=043^A10920=
~^A10938=N^A11340=5-  9.99^A11343=0.20^A
11344=~^A11341=~^A11342=0.15^A11345=10-
14.99^A11348=0.25^A11349=~^A11346=~^A11347=0.15^A11350=15- 19.99^A
11353=0.30^A11354=~^A11351=~^A11352=0.20^A11338=23SEP05^A10981=0^A10485=N^A1
0761=0^A11220=~^A11224=N^A
10808=N^A10921=~^A10960=N^A10957=N^A11329=N^A11286=0^A11214=USA^A10917=Y^A11
288=0^A10906=N^A10737=0.01^A10956=~^A
10967=~^A10965=~^A10809=0^A10762=N^A10763=N^A10712=1^A10905=09:30:00^A10918=
YA0101^A10951=Y^A10469=1^A10949=1^A
10487=Q^A10950=Y^A10899=N^A10380=N^A10696=03^A11082=18.41^A10217=12^A10954=N
^A10708=E^A10958=N^A11213=US ^A
11334=N^A11332=N^A11331=N^A11330=N^A11335=N^A11333=N^A10767=3^A10974=~^A1098
0=AIRTRAN HOLDINGS                ^A
11289=N^A10912=4^A10915=0501^A10914=0501^A10975=N^A10913=SLK^A10698=055^A106
66=AAI^A10903=S^A11328=N^A10624=L^A
11287=0^A10699=0^A10962=L^A11227=SUB1^A11229=5^A11228=1^A11236=16:24:41.521^
A11277=16:25:11.630^A^A10=141^A
 
30226 [SocketIoProcessor] ERROR
quickfix.mina.initiator.InitiatorProtocolHandler  - Invalid message: Actual
body length=1157, Expected body length=1158

Re: [Quickfix-users] user defined types seems to break typesafe cracking in C++

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

Have you tried tracing through the message cracker?  There shouldn't be =
any reason why adding a field would cause the behavior to change.

--oren
  ----- Original Message -----=20
  From: Murphy, Richard=20
  To: qui...@li...=20
  Sent: Friday, March 31, 2006 5:59 AM
  Subject: [Quickfix-users] user defined types seems to break typesafe =
cracking in C++


  Hi,

  =20

  I'm looking at QuickFix user defined types.

  I find that if I add a user defined field to a structure such as a =
FIX44::Quote I find that typesafe message cracking fails.

  What I mean by that is that the the onMessage function that takes =
FIX44::Quote as an argument does not get called.

  If I remove the user defined type then the function does get called.

  =20

  Can you confirm this behaviour ? Is there a workaround ?=20

  I used the procedure documented on the QuickFix doc url.

  =20

  Thanks

  Richard.=20

  =20

  QuickFix Version 1.10.2

  Compiler : g++ (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-42)

  =20

  =20





  =
-------------------------------------------------------------------------=
--------------------

  The information contained in this transmission and any attached =
documents is privileged, confidential and intended only for the use of =
the individual or entity named above. If the reader of this message is =
not the intended recipient, you are hereby directed not to read the =
contents of this transmission, and are hereby notified that any =
disclosure, copying, distribution, dissemination or use of the contents =
of this transmission, including any attachments, or the taking of any =
action in reliance thereon, is strictly prohibited. If you have received =
this communication in error, please notify the sender and/or Citadel =
Investment Group (Europe) Ltd immediately by telephone at +44 (0) 20 =
7645 9700 and destroy any copy of this transmission.

  Citadel Investment Group (Europe) Ltd is authorised and regulated by =
the Financial Services Authority (FSA Firm Ref No 190260).
  Registered in England. Registration No. 3666898.
  Registered Office: 10th Floor, 2 George Yard, Lombard Street, London =
EC3V 9DH

RE: [Quickfix-users] Java Code Generator for FIX messages

[Shepheard, T. \(London\) <Tob...@ml...>]

It generates the java code in the "src-generated" folder, which as the
doc suggests is for the message and field definitions. To do this, it
uses the FIX xml data-dictionary files, which you'll find in the etc
directory (FIX40.xml, FIX44.xml etc). The generate.code build task in
build.xml then runs the JavaCodeGenerator to build the message and field
java code, which is then compiled along with the core java files to
create the jar.
=20
So, in a nutshell you just need to create your own copy of the relevant
FIX xml file, and then run a full build. Make sure you have
UseDataDictionary enabled in your config and specify your own
DataDictionary for these changes to be fully validated when you run your
app.=20
=20
Regards,
Toby

	-----Original Message-----
	From: qui...@li...
[mailto:qui...@li...] On Behalf Of
Parhami, Faraz
	Sent: 02 April 2006 22:40
	To: 'qui...@li...';
'qui...@li...'
	Subject: [Quickfix-users] Java Code Generator for FIX messages
=09
=09
	Does any one know what 'JavaCodeGenerator' class in 'QuickFixJ'
beta generates? The java doc says 'Generates Message and Field related
code for the various FIX versions.'
	=20
	I need to create new User Defined messages with a lot of fields.
Is there a way to generate the code give a config/xml file? Does
'JavaCodeGenerator' do this? If yes, is there an example of how to use
it?
	=20
	Thanks
--------------------------------------------------------

If you are not an intended recipient of this e-mail, please notify the =
sender, delete it and do not read, act upon, print, disclose, copy, =
retain or redistribute it. Click here for important additional terms =
relating to this e-mail.     http://www.ml.com/email_terms/
--------------------------------------------------------

[Quickfix-users] RE: [Quickfix-developers] Build problem on Linux

[Parhami, F. <Far...@gs...>]

Thanks. I will give it a try.=20

-----Original Message-----
From: Joerg Thoennes [mailto:Joe...@ma...]=20
Sent: Monday, April 03, 2006 9:44 AM
To: Parhami, Faraz
Cc: 'qui...@li...';
'qui...@li...'
Subject: Re: [Quickfix-developers] Build problem on Linux

Parhami, Faraz wrote:
> gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-113)
>=20
> Someone told me that most likely the compiler should be broken since=20
> it cannot find the <limit> header. Is that what you are also =
thinking?

I would suggest to use a newer GCC compiler, i.e. 3.3 or 3.4. gcc 2.x =
is
quite old, and if I remember correctly, specifically 2.96 is not
recommended.

Cheers, J=F6rg

--
Joerg Thoennes
                                http://macd.com
Tel.: +49 (0)241 44597-24      Macdonald Associates GmbH
Fax : +49 (0)241 44597-10      Lothringer Str. 52, D-52070 Aachen

[Quickfix-users] Re: [Quickfix-developers] Build problem on Linux

[Joerg T. <Joe...@ma...>]

Parhami, Faraz wrote:
> gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-113)
>=20
> Someone told me that most likely the compiler should be broken since it
> cannot find the <limit> header. Is that what you are also thinking?

I would suggest to use a newer GCC compiler, i.e. 3.3 or 3.4. gcc 2.x is =
quite old, and if=20
I remember correctly, specifically 2.96 is not recommended.

Cheers, J=F6rg

--=20
Joerg Thoennes
                                http://macd.com
Tel.: +49 (0)241 44597-24      Macdonald Associates GmbH
Fax : +49 (0)241 44597-10      Lothringer Str. 52, D-52070 Aachen

[Quickfix-users] RE: [Quickfix-developers] Build problem on Linux

[Parhami, F. <Far...@gs...>]

gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-113)

Someone told me that most likely the compiler should be broken since it
cannot find the <limit> header. Is that what you are also thinking?

Thank you very much
=20
-----Original Message-----
From: Joerg Thoennes [mailto:Joe...@ma...]=20
Sent: Monday, April 03, 2006 9:30 AM
To: Parhami, Faraz
Cc: 'qui...@li...';
'qui...@li...'
Subject: Re: [Quickfix-developers] Build problem on Linux

Parhami, Faraz wrote:
> I am trying to build 'QuickFix 1.11.1' on Linux with java.
>=20
> I did the following:
> ./bootstrap
> ./configure --with-java --disable-xmltest make

What version of C++ compiler are you using? And which Linux =
distribution?

> But 'make' fails with the following output:
> [...]
> make[4]: Entering directory `/home/parhaf/sapi/quickfix/src/C++/test'
> /bin/sh ../../../libtool --mode=3Dcompile c++ -DHAVE_CONFIG_H -I. -I.
> -I../../.. -I..    -g -O2     -I/usr/include/libxml2
> -I/sw/external/jdk-1.4.2_08/include
> -I/sw/external/jdk-1.4.2_08/include/linux  -O0 -g -c=20
> FieldBaseTestCase.cpp
> c++ -DHAVE_CONFIG_H -I. -I. -I../../.. -I.. -g -O2=20
> c++ -I/usr/include/libxml2
> -I/sw/external/jdk-1.4.2_08/include
> -I/sw/external/jdk-1.4.2_08/include/linux -O0 -g
> -Wp,-MD,.deps/FieldBaseTestCase.pp -c FieldBaseTestCase.cpp      =
-fPIC
-DPIC
> -o FieldBaseTestCase.lo
> In file included from ../Field.h:32,
>                  from FieldBaseTestCase.h:26,
>                  from FieldBaseTestCase.cpp:27:
> ../FieldConvertors.h:32:18: limits: No such file or directory

This line tells you, that at line 32, column 18 in the file
FieldConvertors.h, the include file "limits" is missing. This is not a =
make
message, but a message of your C++ compiler.

On my system (Debian 3.1), I can find the "limits" include file here:

/usr/include/c++/3.3/limits
/usr/include/c++/3.4/limits

Cheers, J=F6rg

--
Joerg Thoennes
                                http://macd.com
Tel.: +49 (0)241 44597-24      Macdonald Associates GmbH
Fax : +49 (0)241 44597-10      Lothringer Str. 52, D-52070 Aachen

[Quickfix-users] Re: [Quickfix-developers] Build problem on Linux

[Joerg T. <Joe...@ma...>]

Parhami, Faraz wrote:
> I am trying to build 'QuickFix 1.11.1' on Linux with java.
>=20
> I did the following:
> ./bootstrap
> ./configure --with-java --disable-xmltest
> make

What version of C++ compiler are you using? And which Linux distribution?

> But 'make' fails with the following output:
> [...]
> make[4]: Entering directory `/home/parhaf/sapi/quickfix/src/C++/test'
> /bin/sh ../../../libtool --mode=3Dcompile c++ -DHAVE_CONFIG_H -I. -I.
> -I../../.. -I..    -g -O2     -I/usr/include/libxml2
> -I/sw/external/jdk-1.4.2_08/include
> -I/sw/external/jdk-1.4.2_08/include/linux  -O0 -g -c FieldBaseTestCase.=
cpp
> c++ -DHAVE_CONFIG_H -I. -I. -I../../.. -I.. -g -O2 -I/usr/include/libxm=
l2
> -I/sw/external/jdk-1.4.2_08/include
> -I/sw/external/jdk-1.4.2_08/include/linux -O0 -g
> -Wp,-MD,.deps/FieldBaseTestCase.pp -c FieldBaseTestCase.cpp      -fPIC =
-DPIC
> -o FieldBaseTestCase.lo
> In file included from ../Field.h:32,
>                  from FieldBaseTestCase.h:26,
>                  from FieldBaseTestCase.cpp:27:
> ../FieldConvertors.h:32:18: limits: No such file or directory

This line tells you, that at line 32, column 18 in the file FieldConverto=
rs.h, the include=20
file "limits" is missing. This is not a make message, but a message of yo=
ur C++ compiler.

On my system (Debian 3.1), I can find the "limits" include file here:

/usr/include/c++/3.3/limits
/usr/include/c++/3.4/limits

Cheers, J=F6rg

--=20
Joerg Thoennes
                                http://macd.com
Tel.: +49 (0)241 44597-24      Macdonald Associates GmbH
Fax : +49 (0)241 44597-10      Lothringer Str. 52, D-52070 Aachen

[Quickfix-users] Java Code Generator for FIX messages

[Parhami, F. <Far...@gs...>]

Does any one know what 'JavaCodeGenerator' class in 'QuickFixJ' beta
generates? The java doc says 'Generates Message and Field related code for
the various FIX versions.'
 
I need to create new User Defined messages with a lot of fields. Is there a
way to generate the code give a config/xml file? Does 'JavaCodeGenerator' do
this? If yes, is there an example of how to use it?
 
Thanks

[Quickfix-users] Build problem on Linux

[Parhami, F. <Far...@gs...>]

I am trying to build 'QuickFix 1.11.1' on Linux with java.

I did the following:
./bootstrap
./configure --with-java --disable-xmltest
make

But 'make' fails with the following output:
make  all-recursive
make[1]: Entering directory `/home/parhaf/sapi/quickfix'
Making all in src
make[2]: Entering directory `/home/parhaf/sapi/quickfix/src'
Making all in C++
make[3]: Entering directory `/home/parhaf/sapi/quickfix/src/C++'
Making all in test
make[4]: Entering directory `/home/parhaf/sapi/quickfix/src/C++/test'
/bin/sh ../../../libtool --mode=compile c++ -DHAVE_CONFIG_H -I. -I.
-I../../.. -I..    -g -O2     -I/usr/include/libxml2
-I/sw/external/jdk-1.4.2_08/include
-I/sw/external/jdk-1.4.2_08/include/linux  -O0 -g -c FieldBaseTestCase.cpp
c++ -DHAVE_CONFIG_H -I. -I. -I../../.. -I.. -g -O2 -I/usr/include/libxml2
-I/sw/external/jdk-1.4.2_08/include
-I/sw/external/jdk-1.4.2_08/include/linux -O0 -g
-Wp,-MD,.deps/FieldBaseTestCase.pp -c FieldBaseTestCase.cpp      -fPIC -DPIC
-o FieldBaseTestCase.lo
In file included from ../Field.h:32,
                 from FieldBaseTestCase.h:26,
                 from FieldBaseTestCase.cpp:27:
../FieldConvertors.h:32:18: limits: No such file or directory
make[4]: *** [FieldBaseTestCase.lo] Error 1
make[4]: Leaving directory `/home/parhaf/sapi/quickfix/src/C++/test'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/home/parhaf/sapi/quickfix/src/C++'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/parhaf/sapi/quickfix/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/parhaf/sapi/quickfix'
make: *** [all-recursive-am] Error 2

I don't have much experience with 'make'. Looks like it cannot locate the
'FieldConvertors.h'. Any help would be much appreciated.

Thanks
Faraz

[Quickfix-users] user defined types seems to break typesafe cracking in C++

[Murphy, R. <Ric...@ci...>]

Hi,

 

I'm looking at QuickFix user defined types.

I find that if I add a user defined field to a structure such as a
FIX44::Quote I find that typesafe message cracking fails.

What I mean by that is that the the onMessage function that takes
FIX44::Quote as an argument does not get called.

If I remove the user defined type then the function does get called.

 

Can you confirm this behaviour ? Is there a workaround ? 

I used the procedure documented on the QuickFix doc url.

 

Thanks

Richard. 

 

QuickFix Version 1.10.2

Compiler : g++ (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-42)

 

 





------------------------------------------------------------------------
---------------------

The information contained in this transmission and any attached
documents is privileged, confidential and intended only for the use of
the individual or entity named above. If the reader of this message is
not the intended recipient, you are hereby directed not to read the
contents of this transmission, and are hereby notified that any
disclosure, copying, distribution, dissemination or use of the contents
of this transmission, including any attachments, or the taking of any
action in reliance thereon, is strictly prohibited. If you have received
this communication in error, please notify the sender and/or Citadel
Investment Group (Europe) Ltd immediately by telephone at +44 (0) 20
7645 9700 and destroy any copy of this transmission.

Citadel Investment Group (Europe) Ltd is authorised and regulated by the
Financial Services Authority (FSA Firm Ref No 190260).
Registered in England. Registration No. 3666898.
Registered Office: 10th Floor, 2 George Yard, Lombard Street, London
EC3V 9DH

Re: [Quickfix-users] MessageCracker

[Dale W. <wil...@oc...>]

Charles Sicotte wrote:
>
> If I want my application to handle multiple version of FIX (like 4.1 
> and 4.2).
> If I implement a MessageCracker, do I have to override, the 
> ExecutionReport for example, of each version of FIX? 
As Oren already said, yes.
> What would be the best way to handle multiple version?
The approach I took involves templated member functions.  A typical 
declaration looks like:

      template<typename MESSAGE>
      void onExecutionReport(
        const MESSAGE & message,
        const FIX::SessionID & sessionID);

The virtual methods to be called from the MessageCracker look like:

void
Exchange::onMessage(
  const FIX42::ExecutionReport & message,
  const FIX::SessionID & sessionID)
{
  this->onExecutionReport(message, sessionID);
}

void
Exchange::onMessage(
  const FIX43::ExecutionReport & message,
  const FIX::SessionID & sessionID)
{
  this->onExecutionReport(message, sessionID);
}
etc.

Note the this-> is there to help avoid a nasty template/name resolution 
problem in C++.

Some of the templated methods are messier.  For example

      template<typename MESSAGE, typename GROUP>
      void onMarketDataSnapshotFullRefresh(
        const MESSAGE & message,
        const FIX::SessionID &);

Which has to be called like so:

void
Exchange::onMessage(
  const FIX42::MarketDataSnapshotFullRefresh & message, const 
FIX::SessionID &sessionID)
{
  this->onMarketDataSnapshotFullRefresh
    <FIX42::MarketDataSnapshotFullRefresh, 
FIX42::MarketDataSnapshotFullRefresh::NoMDEntries>
    (message, sessionID);
}

But once you get past the template tricks, you can write common code to 
handle all the protocols (to the extent that they are similar, anyway.)

Note: If you're using VC6 or older versions of gcc, do not try this  -- 
it's painful on old compilers.

HTH,

Dale

Re: [Quickfix-users] MessageCracker

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

Yes.  The FIX.4.1 and FIX.4.2 ExecutionReports will be sent to different 
callbacks.  So you will need to implement a callback for each one.  You 
can pass these into a more generic method which takes a base Message 
class.  You may want to do some processing before hand to make sure the 
messages can be processed by a universal method.  Otherwise just convert 
them into your internal objects before passing them on for processing.

--oren

Charles Sicotte wrote:

> QuickFIX Documentation: 
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Hi,
>
> If I want my application to handle multiple version of FIX (like 4.1 
> and 4.2).
> If I implement a MessageCracker, do I have to override, the 
> ExecutionReport for example, of each version of FIX? What would be the 
> best way to handle multiple version?
>
> Thanks in advance,
>
> Charles
>
>
>
>
> -------------------------------------------------------
> 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
>
>

[Quickfix-users] MessageCracker

[Charles S. <cha...@sy...>]

Hi,

If I want my application to handle multiple version of FIX (like 4.1 and 
4.2).
If I implement a MessageCracker, do I have to override, the ExecutionReport 
for example, of each version of FIX? What would be the best way to handle 
multiple version?

Thanks in advance,

Charles

Re: [Quickfix-users] SessionQualifier and MySQL

[Joerg T. <Joe...@we...>]

Oren Miller wrote:
> Yeah, as I said, the qualifier was designed to be used with initiators.=
 =20
> Also note that you cannot currently set up different acceptor sessions=20
> on different ports.  SocketAcceptPort can only exist in the DEFAULT=20
> section.  Therefore, every acceptor session in a single config file mus=
t=20
> share a port.  This may change in the future, but that is how it is=20
> right now.  Basically, what you are trying to do is not supported=20
> internally.  You would need to run multiple processes to do what you wa=
nt.

Sorry for the confusion I caused. I should have looked at the code instea=
d thinking what=20
should be on the acceptor side.

Maybe we could have a check for SocketAcceptPort outside DEFAULT section?

Cheers, J=F6rg