quickfix-developers — QuickFIX developers forum

Re: [Quickfix-developers] Can't log on: connection drops

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

Nickolai,

You need the Initiator and the Acceptor to take on the role as 
counter-party to the other.  Right now you have set the SenderCompID 
for both to ND1, and the TargetCompID for both to ND2.  In order to 
connect to each other you must reverse one of these.  Essentially you 
are saying that these are identical sessions, so when the acceptor 
receives a logon message from itself it will indeed be confused and 
terminate the connection with extreme prejudice.

You should set one of these sessions to have a SenderCompID of ND2 and 
a TargetCompID of ND1.  Then clear out the files in your FileStorePath 
as it is likely in a confused state.  After that you should be able to 
bring them up and they will happily communicate.

--oren

On Nov 6, 2004, at 10:58 PM, Nickolai Dobrynin wrote:

> QuickFIX Documentation: 
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX FAQ: 
> http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Hi!
>
> I'm very new to this, so please be patient if the
> problem I have was addressed before.
>
> I have a client and a server running on the same
> machine, and every time the initiator tries to log on,
> the connection drops out immediately. Yes, there is a
> FAQ that mentions this, but this FAQ has to do with
> two different computers, where as in my case, only a
> single machine is involved, so it definitely can't be
> due to a time difference.
>
> Here is what happens in my case: on the initiator
> side, onCreate gets called. Then toAdmin produces
> 8=FIX.4.3 9=61 35=A 34=1 49=ND1
> 52=20041107-03:36:31.646 56=ND2 98=0 108=20 10=129
> Then the 'run' function is entered but very briefly,
> as in a matter of seconds, onLogout is called.
>
> My acceptor config file is
>
> [DEFAULT]
> ConnectionType=acceptor
> ReconnectInterval=60
> SenderCompID=ND1
> SocketAcceptPort=9823
> #CheckLatency=N
> MaxLatency=86400
>
> [SESSION]
> BeginString=FIX.4.3
> TargetCompID=ND2
> DataDictionary=/usr/software/quickfix-1.9.2/share/quickfix/FIX43.xml
> StartTime=00:00:00
> EndTime=23:59:59
> FileStorePath=/home/ndobrynin/main/hw
>
> and my initiator config file is
>
> [DEFAULT]
> ConnectionType=initiator
> ReconnectInterval=60
> SenderCompID=ND1
> #CheckLatency=N
> MaxLatency=86400
>
> [SESSION]
> SocketConnectPort=9823
> SocketConnectHost=172.18.121.103
> BeginString=FIX.4.3
> TargetCompID=ND2
> DataDictionary=/usr/software/quickfix-1.9.2/share/quickfix/FIX43.xml
> StartTime=00:00:00
> EndTime=23:59:59
> FileLogPath=/home/ndobrynin/main/hw
> FileStorePath=/home/ndobrynin/main/hw
> HeartBtInt=20
>
> Can anybody please tell me what the problem might be?
>
>
> Many thanks to all,
>
> Nickolai Dobrynin
>
>
> 		
> __________________________________
> Do you Yahoo!?
> Check out the new Yahoo! Front Page.
> www.yahoo.com
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

[Quickfix-developers] Can't log on: connection drops

[Nickolai D. <n_d...@ya...>]

Hi!

I'm very new to this, so please be patient if the
problem I have was addressed before.

I have a client and a server running on the same
machine, and every time the initiator tries to log on,
the connection drops out immediately. Yes, there is a
FAQ that mentions this, but this FAQ has to do with
two different computers, where as in my case, only a
single machine is involved, so it definitely can't be
due to a time difference.

Here is what happens in my case: on the initiator
side, onCreate gets called. Then toAdmin produces
8=FIX.4.3 9=61 35=A 34=1 49=ND1
52=20041107-03:36:31.646 56=ND2 98=0 108=20 10=129
Then the 'run' function is entered but very briefly,
as in a matter of seconds, onLogout is called.

My acceptor config file is

[DEFAULT]
ConnectionType=acceptor
ReconnectInterval=60
SenderCompID=ND1
SocketAcceptPort=9823
#CheckLatency=N
MaxLatency=86400

[SESSION]
BeginString=FIX.4.3
TargetCompID=ND2
DataDictionary=/usr/software/quickfix-1.9.2/share/quickfix/FIX43.xml
StartTime=00:00:00
EndTime=23:59:59
FileStorePath=/home/ndobrynin/main/hw

and my initiator config file is

[DEFAULT]
ConnectionType=initiator
ReconnectInterval=60
SenderCompID=ND1
#CheckLatency=N
MaxLatency=86400

[SESSION]
SocketConnectPort=9823
SocketConnectHost=172.18.121.103
BeginString=FIX.4.3
TargetCompID=ND2
DataDictionary=/usr/software/quickfix-1.9.2/share/quickfix/FIX43.xml
StartTime=00:00:00
EndTime=23:59:59
FileLogPath=/home/ndobrynin/main/hw
FileStorePath=/home/ndobrynin/main/hw
HeartBtInt=20

Can anybody please tell me what the problem might be?


Many thanks to all,

Nickolai Dobrynin


		
__________________________________ 
Do you Yahoo!? 
Check out the new Yahoo! Front Page. 
www.yahoo.com 
 

[Quickfix-developers] Number of instances in a Group

[<em...@co...>]

When parsing a fix message that has a repeating group, how would I be able
to find out the number of elements the repeating group has.

For instance, lets say we have the following group,

    class LinesOfText : public FIX::Group
    {
    public:
    LinesOfText() : FIX::Group(33, 58, FIX::message_order(
        58,
      0)){}
      FIELD_SET(*this, FIX::Text);
    };


how would I be able to know how many 'LinesOfText" instances there will be
in a particular fix message.

Thanks folks,

Emir

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.766 / Virus Database: 513 - Release Date: 9/17/2004
 

Re: [Quickfix-developers] empty sequence number on sequence reset message

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

Actually, on second thought there is no need to change the signature of=20=

Session::verify, rewriting it like this is probably better:

bool Session::verify( const Message& msg, bool checkTooHigh,
                       bool checkTooLow )
{ QF_STACK_PUSH(Session::verify)

   SenderCompID senderCompID;
   TargetCompID targetCompID;
   SendingTime sendingTime;
   MsgType msgType;
   MsgSeqNum msgSeqNum;

   try
   {
     const Header& header =3D msg.getHeader();
     header.getField( senderCompID );
     header.getField( targetCompID );
     header.getField( sendingTime );
     header.getField( msgType );
     if( checkTooHigh || checkTooLow )
       header.getField( msgSeqNum );

     if ( !validLogonState( msgType ) )
       throw std::logic_error( "Logon state is not valid for message" );

     if ( !isGoodTime( sendingTime ) )
     {
       doBadTime( msg );
       return false;
     }
     if ( !isCorrectCompID( senderCompID, targetCompID ) )
     {
       doBadCompID( msg );
       return false;
     }
     if ( checkTooHigh && isTargetTooHigh( msgSeqNum ) )
     {
       doTargetTooHigh( msg );
       return false;
     }
     else if ( checkTooLow && isTargetTooLow( msgSeqNum ) )
     {
       doTargetTooLow( msg );
       return false;
     }

     UtcTimeStamp now;
     m_state.lastReceivedTime( now );
     m_state.testRequest( 0 );
   }
   catch ( std::exception& e )
   {
     m_state.onEvent( e.what() );
     disconnect();
     return false;
   }

   fromCallback( msgType, msg, m_sessionID );
   return true;

   QF_STACK_POP
}

On Nov 4, 2004, at 8:33 AM, Michael Raykh wrote:

> In our test of quickFix against Appia fix engine the following =
happens:
>
> - Appia sends sequence reset request msg
> - for some reason sequence number field is not populated on this reset=20=

> request
> - quickFix decides to reject this
> - crashes in generateReject in
> =A0=A0=A0=A0=A0=A0=A0 =A0 message.getHeader().getField( msgSeqNum );
> =A0=A0 'cause message seq number is not set...
>
>
>
> Is this proper behaviour? Any suggestions how to handle this?
>  This email and any files transmitted with it are confidential and=20
> intended solely for the use of the individual or entity to whom they=20=

> are addressed. If you have received this email in error please notify=20=

> the system manager. This message contains confidential information and=20=

> is intended only for the individual named. If you are not the named=20
> addressee you should not disseminate, distribute or copy this e-mail.=20=

Re: [Quickfix-developers] empty sequence number on sequence reset message

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

Well, when a sequence reset is sent in reset mode (123=3DN) the spec =
says=20
that you should ignore the MsgSeqNum.  I guess Appia took this to mean=20=

that they can choose to just not send it, even though it is listed as a=20=

required field (not conditionally required) in the standard header.

First thing that we should do is have QF gracefully handle rejecting a=20=

message without a sequence number.  This should be accomplished easily=20=

enough by replacing that line with this:

   if( message.getHeader().isSetField( msgSeqNum ) )
     message.getHeader().getField( msgSeqNum );

This will essentially cause the reject message to say it is rejecting=20
the message with sequence number 0, which I think is a reasonable thing=20=

to say if there is no sequence number.

Now the question is do we want to make an exception for this message=20
type and process the message that doesn't contain this required field. =20=

I would say since it is our job to "ignore" it, than yes, we should=20
probably allow it.  To accomplish this we will need to allow the=20
nextSequenceReset method to specify that the validate method should=20
ignore sequence numbers.  We can probably do this by rewriting the=20
method like so:

bool Session::verify( const Message& msg, bool checkTooHigh,
                       bool checkTooLow, bool checkSequenceNumber )
{ QF_STACK_PUSH(Session::verify)

   SenderCompID senderCompID;
   TargetCompID targetCompID;
   SendingTime sendingTime;
   MsgType msgType;
   MsgSeqNum msgSeqNum;

   try
   {
     const Header& header =3D msg.getHeader();
     header.getField( senderCompID );
     header.getField( targetCompID );
     header.getField( sendingTime );
     header.getField( msgType );
     if( checkSequenceNumber )
       header.getField( msgSeqNum );

     if ( !validLogonState( msgType ) )
       throw std::logic_error( "Logon state is not valid for message" );

     if ( !isGoodTime( sendingTime ) )
     {
       doBadTime( msg );
       return false;
     }
     if ( !isCorrectCompID( senderCompID, targetCompID ) )
     {
       doBadCompID( msg );
       return false;
     }
     if ( checkSequenceNumber && checkTooHigh && isTargetTooHigh(=20
msgSeqNum ) )
     {
       doTargetTooHigh( msg );
       return false;
     }
     else if ( checkSequenceNumber && checkTooLow && isTargetTooLow(=20
msgSeqNum ) )
     {
       doTargetTooLow( msg );
       return false;
     }

     UtcTimeStamp now;
     m_state.lastReceivedTime( now );
     m_state.testRequest( 0 );
   }
   catch ( std::exception& e )
   {
     m_state.onEvent( e.what() );
     disconnect();
     return false;
   }

   fromCallback( msgType, msg, m_sessionID );
   return true;

   QF_STACK_POP
}

On Nov 4, 2004, at 8:33 AM, Michael Raykh wrote:

> In our test of quickFix against Appia fix engine the following =
happens:
>
> - Appia sends sequence reset request msg
> - for some reason sequence number field is not populated on this reset=20=

> request
> - quickFix decides to reject this
> - crashes in generateReject in
> =A0=A0=A0=A0=A0=A0=A0 =A0 message.getHeader().getField( msgSeqNum );
> =A0=A0 'cause message seq number is not set...
>
>
>
> Is this proper behaviour? Any suggestions how to handle this?
>  This email and any files transmitted with it are confidential and=20
> intended solely for the use of the individual or entity to whom they=20=

> are addressed. If you have received this email in error please notify=20=

> the system manager. This message contains confidential information and=20=

> is intended only for the individual named. If you are not the named=20
> addressee you should not disseminate, distribute or copy this e-mail.=20=

[Quickfix-developers] empty sequence number on sequence reset message

[Michael R. <mr...@li...>]

In our test of quickFix against Appia fix engine the following happens:

- Appia sends sequence reset request msg
- for some reason sequence number field is not populated on this reset
request
- quickFix decides to reject this
- crashes in generateReject in
	  message.getHeader().getField( msgSeqNum );
   'cause message seq number is not set...


Is this proper behaviour? Any suggestions how to handle this?
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

Re: [Quickfix-developers] Session Qualifiers

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

Indeed.  These should be reversed.  We are also adding support for=20
qualifiers to the other sendToTarget signatures.

--oren

On Nov 3, 2004, at 2:53 PM, John Lister wrote:

> I've looked at this in QF1.9.2 but sendtotarget just adds the session=20=

> id to=A0the message before passing it to the standard SendToTarget, =
this=20
> always fails because of the qualifiers (unless there=A0is=A0another=20
> SendToTarget?)
> =A0
> bool Session::sendToTarget( Message& message, const SessionID&=20
> sessionID )
> throw( SessionNotFound )
> {
>   QF_STACK_PUSH(Session::sendToTarget)
>   message.setSessionID( sessionID );
>   return sendToTarget( message );
>   QF_STACK_POP
> }
> i would have thought that this should be the other way around. ie the=20=

> standard SendToTarget=A0extracts the session information and passes =
that=20
> to expanded version, eg:
> bool Session::sendToTarget( Message& message )
> throw( SessionNotFound )
> { QF_STACK_PUSH(Session::sendToTarget)
>   try
>   {
>     SessionID sessionID =3D message.getSessionID();
> =A0=A0=A0 return sendToTarget( message, sessionID );
>   }
>   catch ( FieldNotFound& ) { throw SessionNotFound(); }
>   QF_STACK_POP
> }
> bool Session::sendToTarget( Message& message, const SessionID&=20
> sessionID )
> throw( SessionNotFound )
> { QF_STACK_PUSH(Session::sendToTarget)
>   message.setSessionID( sessionID );
>   Session* pSession =3D lookupSession( sessionID );
>   if ( !pSession ) throw SessionNotFound();
>   return result =3D pSession->send( message );
>   QF_STACK_POP
> }
>
> before i changed my code i wanted to make sure that nothing else would=20=

> be broken when using qualifiers.
> =A0
> =A0
> ----- Original Message -----
>  From: "Oren Miller" <or...@qu...>
> To: "John Lister" <joh...@sq...>
> Cc: <qui...@li...>
> Sent: Wednesday, November 03, 2004 7:30 PM
> Subject: Re: [Quickfix-developers] Session Qualifiers
>
> Depends on which sendToTarget you use.=A0 Right now you need to use =
the
> method signature that takes in a SessionID as opposed to the ones that
>  take in CompIDs or strings.
>
> --oren
>
> On Nov 3, 2004, at 12:22 PM, John Lister wrote:
>
> > Hi, i've been trying to use session qualifiers but have encountered =
a
>  > problem. Although the session are set up correctly you cannot send =
a
>  > message because senttotarget looks up a session without the=20
> qualifier
> > and fails. Has anyone else encountered this?
> >=A0
> > Thanks
>

Re: [Quickfix-developers] Session Qualifiers

[John L. <joh...@sq...>]

I've looked at this in QF1.9.2 but sendtotarget just adds the session id to 
the message before passing it to the standard SendToTarget, this always 
fails because of the qualifiers (unless there is another SendToTarget?)

bool Session::sendToTarget( Message& message, const SessionID& 
sessionID )throw( SessionNotFound ){  QF_STACK_PUSH(Session::sendToTarget) 
message.setSessionID( sessionID );  return sendToTarget( message ); 
QF_STACK_POP}i would have thought that this should be the other way around. 
ie the standard SendToTarget extracts the session information and passes 
that to expanded version, eg:
bool Session::sendToTarget( Message& message )throw( SessionNotFound ){ 
QF_STACK_PUSH(Session::sendToTarget)  try  {    SessionID sessionID = 
message.getSessionID();    return sendToTarget( message, sessionID );  } 
catch ( FieldNotFound& ) { throw SessionNotFound(); }  QF_STACK_POP}bool 
Session::sendToTarget( Message& message, const SessionID& 
sessionID )throw( SessionNotFound ){ QF_STACK_PUSH(Session::sendToTarget) 
message.setSessionID( sessionID );  Session* pSession = lookupSession( 
sessionID );  if ( !pSession ) throw SessionNotFound();  return result = 
pSession->send( message );  QF_STACK_POP}before i changed my code i wanted 
to make sure that nothing else would be broken when using qualifiers.


----- Original Message ----- 
From: "Oren Miller" <or...@qu...>
To: "John Lister" <joh...@sq...>
Cc: <qui...@li...>
Sent: Wednesday, November 03, 2004 7:30 PM
Subject: Re: [Quickfix-developers] Session Qualifiers


Depends on which sendToTarget you use.  Right now you need to use the
method signature that takes in a SessionID as opposed to the ones that
take in CompIDs or strings.

--oren

On Nov 3, 2004, at 12:22 PM, John Lister wrote:

> Hi, i've been trying to use session qualifiers but have encountered a
> problem. Although the session are set up correctly you cannot send a
> message because senttotarget looks up a session without the qualifier
> and fails. Has anyone else encountered this?
>
> Thanks

Re: [Quickfix-developers] Session Qualifiers

[John L. <joh...@sq...>]

I've looked at this in QF1.9.2 but sendtotarget just adds the session id to 
the message before passing it to the standard sendtotarget - see below




----- Original Message ----- 
From: "Oren Miller" <or...@qu...>
To: "John Lister" <joh...@sq...>
Cc: <qui...@li...>
Sent: Wednesday, November 03, 2004 7:30 PM
Subject: Re: [Quickfix-developers] Session Qualifiers


Depends on which sendToTarget you use.  Right now you need to use the
method signature that takes in a SessionID as opposed to the ones that
take in CompIDs or strings.

--oren

On Nov 3, 2004, at 12:22 PM, John Lister wrote:

> Hi, i've been trying to use session qualifiers but have encountered a 
> problem. Although the session are set up correctly you cannot send a 
> message because senttotarget looks up a session without the qualifier and 
> fails. Has anyone else encountered this?
>  Thanks

Re: [Quickfix-developers] Session Qualifiers

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

Depends on which sendToTarget you use.  Right now you need to use the=20
method signature that takes in a SessionID as opposed to the ones that=20=

take in CompIDs or strings.

--oren

On Nov 3, 2004, at 12:22 PM, John Lister wrote:

> Hi, i've been trying to use session qualifiers but have encountered a=20=

> problem. Although the session are set up correctly you cannot send a=20=

> message because senttotarget looks up a session without the qualifier=20=

> and fails. Has anyone else encountered this?
>  =A0
> Thanks

[Quickfix-developers] Session Qualifiers

[John L. <joh...@sq...>]

Hi, i've been trying to use session qualifiers but have encountered a 
problem. Although the session are set up correctly you cannot send a message 
because senttotarget looks up a session without the qualifier and fails. Has 
anyone else encountered this?

Thanks 

[Quickfix-developers] Session Drops Code Contribution

[Jon D. <jd...@wi...>]

Oren,

I have made a code change which allows us to use our Monitoring tools to
alert us when a customers connection has gone down abnormally - no logout
sequence between the client and acceptor.

Here is the diff if you choose to use it.
$diff Session.cpp cvs/Session.cpp
484,487c484
<     if(!m_state.sentLogout())
<       m_state.onEvent( "Dropped Connection" );
<     else
<       m_state.onEvent( "Disconnecting" );
---
>     m_state.onEvent( "Disconnecting" );

This is based upon what is currently in CVS.

-jd-

Re: [Quickfix-developers] fatal error in java api.

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

Hi Andrew,

> Hello.. This bit of code where I set the null value...
> 
> 	quickfix.fix41.OrderCancelRequest message =
>  	 new quickfix.fix41.OrderCancelRequest
>  	 (new OrigClOrdID("1"),
>  	 new ClOrdID("2"),
>  	 new Symbol("MSFT"),
>  	 new Side(Side.BUY));
> 
> 	message.setString(100, null);
> 
> causes this..
> 
> Unexpected Signal : EXCEPTION_ACCESS_VIOLATION (0xc0000005) occurred at 

Actually, the JNI layer code should check for NULL values and throw a 
java.lang.NullPointerException. This a bit more polite than crashing 
with a Segmentation Violation, but anyway: you should not set a field to 
"null." What result would you expect?

Looking at src/java/Conversions.h:

     136 inline void setString( FIX::FieldMap& map, jint field, jstring 
value )
     137 {
     138   const char* uvalue = ENV::get()->GetStringUTFChars( value, 0 );
     139   map.setField( field, uvalue );
     140   ENV::get()->ReleaseStringUTFChars( value, uvalue );
     141 }

Between lines 138 and 139 a check whether uvalue is NULL should be inserted:

    138a   if ( NULL == uvalue ) {
    138b        return;
    138c   }

In this case, GetStringUTFChars() has already thrown an exception, so it 
is not necessary to throw a new one. This is the default idiom in JNI. I 
still have to check whether this also cares for java null values, i.e. 
whether GetStringsUTF() also checks for a jstring null value.

I submitted a bug report on the QuickFIX bugtracker:

http://www.quickfixengine.org/bugtracker/bug.php?op=show&bugid=27

Cheers, Jörg

-- 
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-developers] fatal error in java api.

[Andrew M. <an...@nm...>]

Hello.. This bit of code where I set the null value...

	quickfix.fix41.OrderCancelRequest message =
 	 new quickfix.fix41.OrderCancelRequest
 	 (new OrigClOrdID("1"),
 	 new ClOrdID("2"),
 	 new Symbol("MSFT"),
 	 new Side(Side.BUY));

	message.setString(100, null);

causes this..

Unexpected Signal : EXCEPTION_ACCESS_VIOLATION (0xc0000005) occurred at 
PC=0x807
8C47
Function=[Unknown.]
Library=z:\j2sdk1.4.2_04\jre\bin\client\jvm.dll

NOTE: We are unable to locate the function name symbol for the error
      just occurred. Please refer to release documentation for possible
      reason and solutions.


Current Java thread:
        at quickfix.Message.setString(Native Method)
        at oms.OmsApplication.cancel41(Unknown Source)
        at oms.OmsApplication$ToAppMessageSpooler.run(Unknown Source)
        at java.lang.Thread.run(Thread.java:534)

Dynamic libraries:
0x00400000 - 0x00406000         z:\j2sdk1.4.2_04\bin\java.exe
0x77F80000 - 0x77FFD000         C:\WINNT\system32\ntdll.dll
0x7C2D0000 - 0x7C332000         C:\WINNT\system32\ADVAPI32.dll
0x7C570000 - 0x7C628000         C:\WINNT\system32\KERNEL32.DLL
0x77D30000 - 0x77DA1000         C:\WINNT\system32\RPCRT4.DLL
0x78000000 - 0x78045000         C:\WINNT\system32\MSVCRT.dll
0x08000000 - 0x08138000         z:\j2sdk1.4.2_04\jre\bin\client\jvm.dll
0x77E10000 - 0x77E75000         C:\WINNT\system32\USER32.dll
0x77F40000 - 0x77F7E000         C:\WINNT\system32\GDI32.DLL
0x77570000 - 0x775A0000         C:\WINNT\system32\WINMM.dll
0x6BD00000 - 0x6BD0D000         C:\WINNT\system32\SYNCOR11.DLL
0x10000000 - 0x10007000         z:\j2sdk1.4.2_04\jre\bin\hpi.dll
0x007C0000 - 0x007CE000         z:\j2sdk1.4.2_04\jre\bin\verify.dll
0x007D0000 - 0x007E9000         z:\j2sdk1.4.2_04\jre\bin\java.dll
0x007F0000 - 0x007FD000         z:\j2sdk1.4.2_04\jre\bin\zip.dll
0x2C5C0000 - 0x2C659000         Z:\javaclasses\quickfix_jni.dll
0x75030000 - 0x75044000         C:\WINNT\system32\WS2_32.dll
0x75020000 - 0x75028000         C:\WINNT\system32\WS2HELP.DLL
0x77A50000 - 0x77B3F000         C:\WINNT\system32\ole32.dll
0x779B0000 - 0x77A4B000         C:\WINNT\system32\OLEAUT32.dll
0x7C3A0000 - 0x7C41B000         C:\WINNT\system32\MSVCP71.dll
0x7C340000 - 0x7C396000         C:\WINNT\system32\MSVCR71.dll
0x2C660000 - 0x2C69F000         C:\WINNT\system32\LIBMYSQL.dll
0x75050000 - 0x75058000         C:\WINNT\system32\WSOCK32.dll
0x2CBD0000 - 0x2CCDF000         Z:\j2sdk1.4.2_04\jre\bin\awt.dll
0x77800000 - 0x7781E000         C:\WINNT\system32\WINSPOOL.DRV
0x76620000 - 0x76630000         C:\WINNT\system32\MPR.DLL
0x75E60000 - 0x75E7A000         C:\WINNT\system32\IMM32.dll
0x2CCE0000 - 0x2CD30000         Z:\j2sdk1.4.2_04\jre\bin\fontmanager.dll
0x72800000 - 0x72846000         C:\WINNT\system32\ddraw.dll
0x728A0000 - 0x728A6000         C:\WINNT\system32\DCIMAN32.dll
0x72CF0000 - 0x72D84000         C:\WINNT\system32\D3DIM700.DLL
0x2CDD0000 - 0x2CDDF000         Z:\j2sdk1.4.2_04\jre\bin\net.dll
0x782C0000 - 0x782CC000         C:\WINNT\System32\rnr20.dll
0x77980000 - 0x779A4000         C:\WINNT\system32\DNSAPI.DLL
0x77340000 - 0x77353000         C:\WINNT\system32\iphlpapi.dll
0x77520000 - 0x77525000         C:\WINNT\system32\ICMP.DLL
0x77320000 - 0x77337000         C:\WINNT\system32\MPRAPI.DLL
0x75150000 - 0x7515F000         C:\WINNT\system32\SAMLIB.DLL
0x75170000 - 0x751BF000         C:\WINNT\system32\NETAPI32.DLL
0x2CDE0000 - 0x2CDEF000         C:\WINNT\system32\SECUR32.DLL
0x751C0000 - 0x751C6000         C:\WINNT\system32\NETRAP.DLL
0x77950000 - 0x7797A000         C:\WINNT\system32\WLDAP32.DLL
0x773B0000 - 0x773DF000         C:\WINNT\system32\ACTIVEDS.DLL
0x77380000 - 0x773A3000         C:\WINNT\system32\ADSLDPC.DLL
0x77830000 - 0x7783E000         C:\WINNT\system32\RTUTILS.DLL
0x77880000 - 0x7790E000         C:\WINNT\system32\SETUPAPI.DLL
0x7C0F0000 - 0x7C151000         C:\WINNT\system32\USERENV.DLL
0x774E0000 - 0x77513000         C:\WINNT\system32\RASAPI32.DLL
0x774C0000 - 0x774D1000         C:\WINNT\system32\RASMAN.DLL
0x77530000 - 0x77552000         C:\WINNT\system32\TAPI32.DLL
0x71710000 - 0x71794000         C:\WINNT\system32\COMCTL32.DLL
0x70A70000 - 0x70AD5000         C:\WINNT\system32\SHLWAPI.DLL
0x77360000 - 0x77379000         C:\WINNT\system32\DHCPCSVC.DLL
0x777E0000 - 0x777E8000         C:\WINNT\System32\winrnr.dll
0x777F0000 - 0x777F5000         C:\WINNT\system32\rasadhlp.dll
0x74FD0000 - 0x74FEE000         C:\WINNT\system32\msafd.dll
0x75010000 - 0x75017000         C:\WINNT\System32\wshtcpip.dll
0x2D410000 - 0x2D42B000         Z:\javaclasses\corojdk11.dll
0x772B0000 - 0x7731C000         C:\WINNT\system32\RICHED20.DLL
0x77920000 - 0x77943000         C:\WINNT\system32\imagehlp.dll
0x72A00000 - 0x72A2D000         C:\WINNT\system32\DBGHELP.dll
0x690A0000 - 0x690AB000         C:\WINNT\system32\PSAPI.DLL

Heap at VM Abort:
Heap
 def new generation   total 9216K, used 8624K [0x10010000, 0x10a00000, 
0x11d9000
0)
  eden space 8256K,  99% used [0x10010000, 0x1081ffe0, 0x10820000)
  from space 960K,  38% used [0x10820000, 0x1087c368, 0x10910000)
  to   space 960K,   0% used [0x10910000, 0x10910000, 0x10a00000)
 tenured generation   total 121024K, used 20215K [0x11d90000, 0x193c0000, 
0x2801
0000)
   the space 121024K,  16% used [0x11d90000, 0x1314df68, 0x1314e000, 
0x193c0000)

 compacting perm gen  total 15872K, used 15757K [0x28010000, 0x28f90000, 
0x2c010
000)
   the space 15872K,  99% used [0x28010000, 0x28f73588, 0x28f73600, 
0x28f90000)

Local Time = Tue Nov 02 14:46:30 2004
Elapsed Time = 115
#
# HotSpot Virtual Machine Error : EXCEPTION_ACCESS_VIOLATION
# Error ID : 4F530E43505002EF
# Please report this error at
# http://java.sun.com/cgi-bin/bugreport.cgi
#
# Java VM: Java HotSpot(TM) Client VM (1.4.2_04-b05 mixed mode)
#
# An error report file has been saved as hs_err_pid1236.log.
# Please refer to the file for further information.

Re: [Quickfix-developers] 1.9.3 release date??

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

What we have in CVS is the 1.9.3 release candidate.  This will be the =20=

release once we are happy with it.  The current expectation is the =20
release will go out this week.

--oren

On Nov 2, 2004, at 1:01 AM, Shamanth wrote:

> Hi Oren
>
> Can you give a rough idea of when we can expect 1.9.3 release of =20
> quickfix. I very badly want to use the weeklong session feature of =20
> 1.9.2, but am unable to do so due the the problem of "body length =20
> mismatch" error in 1.9.2.
>
> Please refer the attached mails for the problems I am facing.
>
> thansk
>  R Shamanth
>
>
>
>
>
>  <<Re: [Quickfix-users] Logon Ack seqNo>> <<Re: [Quickfix-users] 1.9.2 =
=20
> body lenght mismatch>>
>
> From: "Oren Miller" <or...@qu...>
> Date: October 19, 2004 10:05:58 AM CDT
> To: "Oren Miller" <or...@qu...>
> Cc: <qui...@li...>, "Shamanth" =20
> <sha...@in...>, <qui...@li...>
> Subject: Re: [Quickfix-users] Logon Ack seqNo
>
>
> Correction:
>
>
>
>  That condition should read, 'endSeqNo >=3D getExpectedSenderNum()'
>
>
>
>  On Oct 19, 2004, at 9:59 AM, Oren Miller wrote:
>
>
>
>  Answer1:
>
>
>
>  No. This is in fact normal behavior. Whenever a message is sent the =20=

> sequence number has to be incremented. Just because we did not receive =
=20
> an ack, does not necessarily mean the counter-party did not receive =20=

> the logon. If the sequence number was not incremented, and they had =20=

> actually received it without acknowledging, you would then encounter =20=

> disconnect scenarios due to too low sequence numbers at some point. A =20=

> much worse position to be in as it cannot be resolved automatically.
>
>
>
>  Having a sequence number that is too high isn't much of a problem =20
> since the two engines can resolve this on their own. And since in this =
=20
> case we are talking about logon messages, all that is required is a =20=

> single gap fill message to put everything in order.
>
>
>
>  Answer2:
>
>
>
>  Depends on the version. For FIX.4.2 and higher, the value should be =20=

> 0. For versions 4.1 and earlier, a special value of 999999 is used. =20=

> I'm a bit curious as to what is going on here. Is both the initiator =20=

> and acceptor QuickFIX. It seems strange because since QuickFIX 1.6, =20=

> the EndSeqNo is always send either 0 or 999999, never another value. =20=

> Based on this I'm guessing the acceptor in this scenario is not =20
> QuickFIX, is this correct?
>
>
>
>  As to the effect of the value 2147483647, I suspect your application =20=

> has stopped responding because you now got the message store trying to =
=20
> look up a hell of a lot of messages in a tight loop. I suspect we can =20=

> have QuickFIX handle this situation more gracefully if we consider =20
> such a situation equivalent to an infinite request as such:
>
>
>
>  if ( beginString >=3D FIX::BeginString_FIX42 && endSeqNo =3D=3D 0 ||
>
>  beginString <=3D FIX::BeginString_FIX42 && endSeqNo =3D=3D 999999 ||
>
>  endSeqNo >=3D getExpectedSeqNum() ) // new condition to handle =20
> bizarrely large numbers
>
>  { endSeqNo =3D getExpectedSenderNum() - 1; }
>
>
>
>
>  On Oct 19, 2004, at 7:08 AM, Shamanth wrote:
>
>
>
>
> Hi
>
>
>
> I am using quickfix 1.8,
>
>
>
> While testing due to some network problems we got disconnected from =20=

> the "Acceptor". In the mean time, our "initiator" tried reconnecting =20=

> to the "acceptor" every 30secs.
>
>
>
> It tried it 8 times before it could get an ack for its logon message.
>
>
>
>
> Problem1: Our initiator, sent 8 logon messages and only the 9th logon =20=

> message was ack by the acceptor. But in the meantime, our initiator =20=

> incremented its MsgSeqNo, so when both the initiator and acceptor got =20=

> connected, there was a mismatch of SeqNo, and the =E2=80=9Cacceptor=E2=80=
=9D send a =20
> resendRequest to the =E2=80=9Cinitiator=E2=80=9D
>
>
>
> Question: Is there a way we can prevent the quickfix initiator from =20=

> incrementing its SeqNo, if it did not receive Ack for its Logon msg.
>
>
>
> NOTE: Only the SeqNo of the messages sent was incremented, while the =20=

> SeqNo of the messages received was correct.
>
>
>
>
>
> Problem2: After connecting again the Acceptor sent, a resend request =20=

> FROM: 0 TO: 2147483647, our initiator had not sent so many messages, =20=

> so it considers it as an error condition and stops responding to the =20=

> acceptor. Is =E2=80=9C2147483647=E2=80=9D the maximum value in resend =
request as per =20
> fix protocol or should =E2=80=9C0=E2=80=9D(infinity) be considered as =
the max valueis =20
> considered as the maximum number?
>
>
>
>
> thanks
>
>
>
>
> R Shamanth
>
>
> From: "Oren Miller" <or...@qu...>
> Date: October 20, 2004 9:56:52 AM CDT
> To: "Shamanth" <sha...@in...>
> Cc: <qui...@li...>, =20
> <qui...@li...>
> Subject: Re: [Quickfix-users] 1.9.2 body lenght mismatch
>
>
> Shamanth,
>
>
>
>  This looks like a problem that has been fixed. The fix is available =20=

> in CVS and will be released with 1.9.3
>
>
>
>  --oren
>
>
>
>  On Oct 20, 2004, at 4:23 AM, Shamanth wrote:
>
>
>
>  Hi
>
> =C2=A0
>
>  I am currently using quickfix 1.8, I wanted to upgrade to 1.9.2, so I =
=20
> downloaded the source and build them in windows.
>
> Both my Initiator and Acceptor are quickfix 1.9.2, I use JNI wrappers, =
=20
> and not the C++ code directly
>
> =C2=A0
>
>  Problem:
>
> When I send a MarketDataRequest, I get the following error in the =20
> Acceptor, I have pasted the original message also below.
>
> =C2=A0
>
>  <20041020-08:37:50, FIX.4.2:ITLServer->ITLClientMD, incoming>
>
> =
=C2=A0(8=3DFIX.4.2=E2=98=BA9=3D151=E2=98=BA35=3DV=E2=98=BA34=3D2=E2=98=BA4=
9=3DITLClientMD=E2=98=BA52=3D2004102008:37:=20
> =
50.617=E2=98=BA56=3DITLServer=E2=98=BA146=3D1=E2=98=BA55=3DEUR/USD=E2=98=BA=
146=3D1=E2=98=BA55=3DEUR/USD=E2=98=BA146=3D1=E2=98=BA55=3DEUR/=20
> =
USD=E2=98=BA262=3D123456=E2=98=BA263=3D1=E2=98=BA264=3D0=E2=98=BA265=3D1=E2=
=98=BA267=3D2=E2=98=BA269=3D0=E2=98=BA269=3D1=E2=98=BA267=3D2=E2=98=BA269=3D=
0=E2=98=BA269=3D1=E2=98=BA26=20
> 7=3D2=E2=98=BA269=3D0=E2=98=BA269=3D1=E2=98=BA10=3D165=E2=98=BA)
>
> <20041020-08:37:50, FIX.4.2:ITLServer->ITLClientMD, event>
>
> =C2=A0 (Invalid message: Expected BodyLength=3D197, Recieved =
BodyLength=3D151)
>
> =C2=A0
>
>  In my initiator log, I am printing the XML of the message before =20
> sending, I see that it is not getting resolved properly
>
> <message>
>
>
>
> =C2=A0 <header>
>
>
>
> =C2=A0=C2=A0=C2=A0 <field number=3D"8"><![CDATA[FIX.4.2]]></field>
>
>
>
> =C2=A0=C2=A0=C2=A0 <field number=3D"35"><![CDATA[V]]></field>
>
>
>
> =C2=A0=C2=A0=C2=A0 <field number=3D"34"><![CDATA[2]]></field>
>
>
>
> =C2=A0=C2=A0=C2=A0 <field number=3D"49"><![CDATA[ITLClientMD]]></field>
>
>
>
> =C2=A0=C2=A0=C2=A0 <field =
number=3D"52"><![CDATA[20041020-08:37:50.617]]></field>
>
>
>
> =C2=A0=C2=A0=C2=A0 <field number=3D"56"><![CDATA[ITLServer]]></field>
>
>
>
> =C2=A0 </header>
>
>
>
> =C2=A0 <body>
>
>
>
> =C2=A0=C2=A0=C2=A0 <field number=3D"146"><![CDATA[1]]></field>
>
>
>
> =C2=A0=C2=A0=C2=A0 <field number=3D"146"><![CDATA[1]]></field>
>
>
>
> =C2=A0=C2=A0=C2=A0 <field number=3D"262"><![CDATA[123456]]></field>
>
>
>
> =C2=A0=C2=A0=C2=A0 <field number=3D"263"><![CDATA[1]]></field>
>
>
>
> =C2=A0=C2=A0=C2=A0 <field number=3D"264"><![CDATA[0]]></field>
>
>
>
> =C2=A0=C2=A0=C2=A0 <field number=3D"265"><![CDATA[1]]></field>
>
>
>
> =C2=A0=C2=A0=C2=A0 <field number=3D"267"><![CDATA[2]]></field>
>
>
>
> =C2=A0=C2=A0=C2=A0 <field number=3D"267"><![CDATA[2]]></field>
>
>
>
> =C2=A0=C2=A0=C2=A0 <group>
>
>
>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <field =
number=3D"55"><![CDATA[EUR/USD]]></field>
>
>
>
> =C2=A0=C2=A0=C2=A0 </group>
>
>
>
> =C2=A0=C2=A0=C2=A0 <group>
>
>
>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <field =
number=3D"269"><![CDATA[0]]></field>
>
>
>
> =C2=A0=C2=A0=C2=A0 </group>
>
>
>
> =C2=A0=C2=A0=C2=A0 <group>
>
>
>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <field =
number=3D"269"><![CDATA[1]]></field>
>
>
>
> =C2=A0=C2=A0=C2=A0 </group>
>
>
>
> =C2=A0 </body>
>
>
>
> =C2=A0 <trailer>
>
>
>
> =C2=A0 </trailer>
>
>
>
> =C2=A0
>
>  Note: If I replace the quickfix.jar, quickfix.lib and =20
> quickfix_jni.dll of 1.8, then every thing works fine. I notice this =20=

> problem only with 1.9.2 jars and dlls.
>
> =C2=A0
>
>  This is how the XML looks with 1.8 jars and dlls
>
> =C2=A0
>
>  <message>
>
>
>
> =C2=A0 <header>
>
>
>
> =C2=A0=C2=A0=C2=A0 <field number=3D"8" value=3D"FIX.4.2"/>
>
>
>
> =C2=A0=C2=A0=C2=A0 <field number=3D"35" value=3D"V"/>
>
>
>
> =C2=A0=C2=A0=C2=A0 <field number=3D"34" value=3D"2"/>
>
>
>
> =C2=A0=C2=A0=C2=A0 <field number=3D"49" value=3D"ITLClientMD"/>
>
>
>
> =C2=A0=C2=A0=C2=A0 <field number=3D"52" =
value=3D"20041020-08:47:49.679"/>
>
>
>
> =C2=A0=C2=A0=C2=A0 <field number=3D"56" value=3D"ITLServer"/>
>
>
>
> =C2=A0 </header>
>
>
>
> =C2=A0 <body>
>
>
>
> =C2=A0=C2=A0=C2=A0 <field number=3D"146" value=3D"1"/>
>
>
>
> =C2=A0=C2=A0=C2=A0 <field number=3D"262" value=3D"123456"/>
>
>
>
> =C2=A0=C2=A0=C2=A0 <field number=3D"263" value=3D"1"/>
>
>
>
> =C2=A0=C2=A0=C2=A0 <field number=3D"264" value=3D"0"/>
>
>
>
> =C2=A0=C2=A0=C2=A0 <field number=3D"265" value=3D"1"/>
>
>
>
> =C2=A0=C2=A0=C2=A0 <field number=3D"267" value=3D"2"/>
>
>
>
> =C2=A0=C2=A0=C2=A0 <group>
>
>
>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <field number=3D"55" value=3D"EUR/USD"/>
>
>
>
> =C2=A0=C2=A0=C2=A0 </group>
>
>
>
> =C2=A0=C2=A0=C2=A0 <group>
>
>
>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <field number=3D"269" value=3D"0"/>
>
>
>
> =C2=A0=C2=A0=C2=A0 </group>
>
>
>
> =C2=A0=C2=A0=C2=A0 <group>
>
>
>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <field number=3D"269" value=3D"1"/>
>
>
>
> =C2=A0=C2=A0=C2=A0 </group>
>
>
>
> =C2=A0 </body>
>
>
>
> =C2=A0 <trailer>
>
>
>
> =C2=A0 </trailer>
>
>
>
> </message>
>
>
>
> =C2=A0
>
>  any idea what could be the problem, has any one else faced the same =20=

> problem.
>
> =C2=A0
>
>  thanks
>
> R Shamanth

Re: [Quickfix-developers] User Request and User Response Fields

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

No Patrick, it's an oversight.  They are being added now.

--oren

On Nov 1, 2004, at 8:32 AM, Patrick Flannery wrote:

> QuickFIX Documentation: 
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX FAQ: 
> http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Oren,
> 	I noticed that none of the quickfix releases include the User
> Request or User Response message as shown in the fix specification.  
> Is this
> normal or have I just not found them?
>
> Patrick Flannery
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

[Quickfix-developers] User Request and User Response Fields

[Patrick F. <pat...@ch...>]

Oren,
	I noticed that none of the quickfix releases include the User
Request or User Response message as shown in the fix specification.  Is this
normal or have I just not found them?

Patrick Flannery

Re: [Quickfix-developers] Field with embedded null character

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

Ok, I checked in the changes along with new unit tests for the Message 
and Parser classes.

--oren

On Oct 29, 2004, at 3:43 PM, Yihu Fang wrote:

> Caleb, Thanks for the patch.
>
> Oren, when you have an extra null byte, the bodylength value increases
> by 1. So the checksum should increase by 1 too.
>
> -Yihu
>
> -----Original Message-----
> From: Oren Miller [mailto:or...@qu...]
> Sent: Friday, October 29, 2004 3:59 PM
> To: Caleb Epstein
> Cc: Yihu Fang; qui...@li...
> Subject: Re: [Quickfix-developers] Field with embedded null character
>
> I added some unit tests and it seems to work except for one problem.  I
> have a message that I'm passing into the messages constructor, which is
> just a normal message.  The checksum of this message is 218.  The test
> is that I send the same message in except I added a null character at
> the end of one of the fields.  It is able to parse everything fine, but
> it determines that the checksum of the message with the null should be
> 219 and throws an Invalid message.  Now since null has a value of 0 I
> would expect that the checksum of these two messages should be
> identical.  Anybody see any flaw in this reasoning?
>
> --oren
>
> On Oct 29, 2004, at 9:37 AM, Caleb Epstein wrote:
>
>> Attached is a comprehensive patch to QuickFIX 1.9.2 with the necessary
>> changes to Field.h, Parser.cpp and ThreadedSocketConnector.{cpp,h} to
>> deal with NUL bytes in messages.
>>
>> Clearly this must be a pretty uncommon need, otherwise it would have
>> been raised on this list before, but if anyone plans on using
>> encrypted messages or moving around messages with binary Data fields,
>> this patch would be a big win.
>>
>> -- 
>> Caleb Epstein
>> cal...@gm...
>> <quickfix-1.9.2-allow-nuls.diff>
>
>
>
>
> -----------------------------------------------------------------
>         Visit our Internet site at http://www.reuters.com
>
> Get closer to the financial markets with Reuters Messaging - for more
> information and to register, visit http://www.reuters.com/messaging
>
> Any views expressed in this message are those of  the  individual
> sender,  except  where  the sender specifically states them to be
> the views of Reuters Ltd.
>
>

Re: [Quickfix-developers] Field with embedded null character

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

Right!

On Oct 29, 2004, at 3:43 PM, Yihu Fang wrote:

> Caleb, Thanks for the patch.
>
> Oren, when you have an extra null byte, the bodylength value increases
> by 1. So the checksum should increase by 1 too.
>
> -Yihu
>
> -----Original Message-----
> From: Oren Miller [mailto:or...@qu...]
> Sent: Friday, October 29, 2004 3:59 PM
> To: Caleb Epstein
> Cc: Yihu Fang; qui...@li...
> Subject: Re: [Quickfix-developers] Field with embedded null character
>
> I added some unit tests and it seems to work except for one problem.  I
> have a message that I'm passing into the messages constructor, which is
> just a normal message.  The checksum of this message is 218.  The test
> is that I send the same message in except I added a null character at
> the end of one of the fields.  It is able to parse everything fine, but
> it determines that the checksum of the message with the null should be
> 219 and throws an Invalid message.  Now since null has a value of 0 I
> would expect that the checksum of these two messages should be
> identical.  Anybody see any flaw in this reasoning?
>
> --oren
>
> On Oct 29, 2004, at 9:37 AM, Caleb Epstein wrote:
>
>> Attached is a comprehensive patch to QuickFIX 1.9.2 with the necessary
>> changes to Field.h, Parser.cpp and ThreadedSocketConnector.{cpp,h} to
>> deal with NUL bytes in messages.
>>
>> Clearly this must be a pretty uncommon need, otherwise it would have
>> been raised on this list before, but if anyone plans on using
>> encrypted messages or moving around messages with binary Data fields,
>> this patch would be a big win.
>>
>> -- 
>> Caleb Epstein
>> cal...@gm...
>> <quickfix-1.9.2-allow-nuls.diff>
>
>
>
>
> -----------------------------------------------------------------
>         Visit our Internet site at http://www.reuters.com
>
> Get closer to the financial markets with Reuters Messaging - for more
> information and to register, visit http://www.reuters.com/messaging
>
> Any views expressed in this message are those of  the  individual
> sender,  except  where  the sender specifically states them to be
> the views of Reuters Ltd.
>
>

RE: [Quickfix-developers] Field with embedded null character

[Yihu F. <Yih...@re...>]

Caleb, Thanks for the patch.

Oren, when you have an extra null byte, the bodylength value increases
by 1. So the checksum should increase by 1 too.

-Yihu

-----Original Message-----
From: Oren Miller [mailto:or...@qu...]=20
Sent: Friday, October 29, 2004 3:59 PM
To: Caleb Epstein
Cc: Yihu Fang; qui...@li...
Subject: Re: [Quickfix-developers] Field with embedded null character

I added some unit tests and it seems to work except for one problem.  I=20
have a message that I'm passing into the messages constructor, which is=20
just a normal message.  The checksum of this message is 218.  The test=20
is that I send the same message in except I added a null character at=20
the end of one of the fields.  It is able to parse everything fine, but=20
it determines that the checksum of the message with the null should be=20
219 and throws an Invalid message.  Now since null has a value of 0 I=20
would expect that the checksum of these two messages should be=20
identical.  Anybody see any flaw in this reasoning?

--oren

On Oct 29, 2004, at 9:37 AM, Caleb Epstein wrote:

> Attached is a comprehensive patch to QuickFIX 1.9.2 with the necessary
> changes to Field.h, Parser.cpp and ThreadedSocketConnector.{cpp,h} to
> deal with NUL bytes in messages.
>
> Clearly this must be a pretty uncommon need, otherwise it would have
> been raised on this list before, but if anyone plans on using
> encrypted messages or moving around messages with binary Data fields,
> this patch would be a big win.
>
> --=20
> Caleb Epstein
> cal...@gm...
> <quickfix-1.9.2-allow-nuls.diff>




-----------------------------------------------------------------
        Visit our Internet site at http://www.reuters.com

Get closer to the financial markets with Reuters Messaging - for more
information and to register, visit http://www.reuters.com/messaging

Any views expressed in this message are those of  the  individual
sender,  except  where  the sender specifically states them to be
the views of Reuters Ltd.

Re: [Quickfix-developers] Field with embedded null character

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

I added some unit tests and it seems to work except for one problem.  I 
have a message that I'm passing into the messages constructor, which is 
just a normal message.  The checksum of this message is 218.  The test 
is that I send the same message in except I added a null character at 
the end of one of the fields.  It is able to parse everything fine, but 
it determines that the checksum of the message with the null should be 
219 and throws an Invalid message.  Now since null has a value of 0 I 
would expect that the checksum of these two messages should be 
identical.  Anybody see any flaw in this reasoning?

--oren

On Oct 29, 2004, at 9:37 AM, Caleb Epstein wrote:

> Attached is a comprehensive patch to QuickFIX 1.9.2 with the necessary
> changes to Field.h, Parser.cpp and ThreadedSocketConnector.{cpp,h} to
> deal with NUL bytes in messages.
>
> Clearly this must be a pretty uncommon need, otherwise it would have
> been raised on this list before, but if anyone plans on using
> encrypted messages or moving around messages with binary Data fields,
> this patch would be a big win.
>
> -- 
> Caleb Epstein
> cal...@gm...
> <quickfix-1.9.2-allow-nuls.diff>

Re: [Quickfix-developers] Field with embedded null character

[Caleb E. <cal...@gm...>]

Attached is a comprehensive patch to QuickFIX 1.9.2 with the necessary
changes to Field.h, Parser.cpp and ThreadedSocketConnector.{cpp,h} to
deal with NUL bytes in messages.

Clearly this must be a pretty uncommon need, otherwise it would have
been raised on this list before, but if anyone plans on using
encrypted messages or moving around messages with binary Data fields,
this patch would be a big win.

-- 
Caleb Epstein
cal...@gm...

Re: [Quickfix-developers] Field with embedded null character

[Caleb E. <cal...@gm...>]

On Thu, 28 Oct 2004 16:54:46 -0400, Yihu Fang <yih...@re...> wrote:

> Actually I am thinking what if a FIX engine sends a FIX message which
> has embedded null character. After the message read off the socket
> (which is a character array), the rest of the code is using STL string
> to represent the message. A null character will basically truncate the
> string.

No, thats not correct.  STL strings can contain \0 bytes.  There are a
couple of other bugs that are due to using char* buffers.

In Parser.cpp, line 152 reads:

   m_buffer += m_readBuffer;

This should be changed to:

  m_buffer.append (m_readBuffer, size);

This fixes the sending side of things, but on the receive side, the
ThreadedSocketConnection needs an overhaul to deal with data that
could contain NUL bytes.  The simplest change would probably be to use
a Queue<std::pair<size_t, char*> > and just include the length along
with each buffer.

-- 
Caleb Epstein
cal...@gm...

RE: [Quickfix-developers] Field with embedded null character

[Yihu F. <Yih...@re...>]

Hi,

Actually I am thinking what if a FIX engine sends a FIX message which
has embedded null character. After the message read off the socket
(which is a character array), the rest of the code is using STL string
to represent the message. A null character will basically truncate the
string.

For example, this message with an extra null in 55=3DIBM<null><soh>
=20
8=3DFIX.4.0<soh>9=3D71<soh>35=3DD<soh>49=3DFIRM0<soh>56=3DFIRM1<soh>11=3D12=
3<soh>21=3D
1<soh>38=3D456<soh>40=3D2<soh>44=3D789<soh>54=3D1<soh>55=3DIBM<null><soh>59=
=3D0<soh>
10=3D157<soh>

In Parser::readFixMessage, extractLength will extract the length of the
message which is larger than m_buffer.size() because m_buffer is a
string and the null character terminate the string in the middle of the
message.

This will in turn drop the whole character buffer in
ThreadedSocketConnection::readQueue() even if the buffer could have a
multiple FIX message in it.

There is no exception or error log in such a scenario.

How should QF handle this case?

Thanks.

-Yihu



-----Original Message-----
From: Caleb Epstein [mailto:cal...@gm...]=20
Sent: Thursday, October 28, 2004 9:06 AM
To: Yihu Fang
Cc: qui...@li...; Oren Miller
Subject: Re: [Quickfix-developers] Field with embedded null character

On Wed, 27 Oct 2004 21:23:04 -0400, Yihu Fang <yih...@re...>
wrote:
> However, in QuickFIX message constructor, it takes string as the
parameter.
> It will throw an invalid message exception because it thinks the
string is
> truncated at the null character and cannot find the Tag 10.=20

Make sure you construct the string you pass to the Message constructor
properly.  The std::string constructor can take a const char* with or
without a length.  If you don't pass the length, it'll stop at the
first embedded \0 and you'll end up with a truncated message.

That said, it does seem that QuickFIX has a bug in the message
serialization code when dealing with fields having embedded \0 bytes:

#include <quickfix/Message.h>
#include <iostream>

using namespace FIX; using namespace std;

int main () {
  Message m;
  m.setField (1000, string ("one\0", 4));
  cout << m.toString () << endl;
  cout << m.getField (1000) << endl;
}

Gives the output (where ^A =3D ASCII SOH and \0 is an ASCII NULL)

9=3D10^A1000=3D one^A10=3D057^A
one\0

Note extra space and lack of \0 for serialized message form.

--=20
Caleb Epstein
cal...@gm...



-----------------------------------------------------------------
        Visit our Internet site at http://www.reuters.com

Get closer to the financial markets with Reuters Messaging - for more
information and to register, visit http://www.reuters.com/messaging

Any views expressed in this message are those of  the  individual
sender,  except  where  the sender specifically states them to be
the views of Reuters Ltd.

Re: [Quickfix-developers] Fixed spurious System.NullReferenceException in .NET Application.toApp()

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

Ok.  I have a fix for this.  In addition to the previous patch, you 
also need to patch Session.cpp and pin the messages before they get 
passed into the native sendToTarget:

120c120,121
<     return FIX::Session::sendToTarget( message->unmanaged() );
---
 >     Message __pin * pMessage = message;
 >     return FIX::Session::sendToTarget( pMessage->unmanaged() );
133c134,135
<     return FIX::Session::sendToTarget( message->unmanaged(),
---
 >     Message __pin * pMessage = message;
 >     return FIX::Session::sendToTarget( pMessage->unmanaged(),
147a150
 >     Message __pin * pMessage = message;
149c152
<            ( message->unmanaged(),
---
 >            ( pMessage->unmanaged(),

After doing this, the crashing stopped completely.

--oren

On Oct 28, 2004, at 9:13 AM, John Debay wrote:

> QuickFIX Documentation: 
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX FAQ: 
> http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> on 10/19/2004 12:03 PM Vladimir Arnost wrote:
>
>> QuickFIX Documentation: 
>> http://www.quickfixengine.org/quickfix/doc/html/index.html
>> QuickFIX FAQ: 
>> http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
>> QuickFIX Support: http://www.quickfixengine.org/services.html
>>
>> Oren,
>>
>> I have fixed a nasty bug in .NET Application class in QuickFIX 1.9.2.
>> From time to time, especially under high system load, sending a FIX
>> message throws an exception like this one:
>>
>> System.NullReferenceException: Object reference not set to an instance
>> of an object.
>>   at FIX.message_order.=(message_order* , message_order* )
>>   at FIX.message_order.__ctor(message_order* , message_order* copy)
>>   at
>> std._Tree<std::_Tmap_traits<int,FIX::FieldBase,FIX::message_order,...>
>>
>>> .key_comp(_Tree<...>* , message_order* )
>>>
>>   at FIX.FieldMap.=(FieldMap* , FieldMap* )
>>   at FIX.Message.=(Message* , Message* )
>>   at Application.toApp(Application* , Message* message, SessionID*
>> sessionID)
>>   at FIX.Session.sendToTarget(Message* , SessionID* )
>>   at QuickFix.Session.sendToTarget(Message message, SessionID
>> sessionID)
>>
>>
> Hi,
>
> Is anyone still seeing this issue occur after applying Vladimir's 
> patch? We have applied it to our code, and are still seeing them same 
> exceptions arise. It is causing a major problem for us in production 
> code, and I'm looking for some feedback from other users out there 
> that may be contending with the same thing.
>
> Thanks,
> John
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>