quickfix-developers — QuickFIX developers forum

Re: [Quickfix-developers] Threading issue

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

Indeed.  Which on a 32 bit machine will give you something on the order 
of 2.14 billion sequence numbers, or 24,800 messages per second 
continuously for a 24 hour session, and 3,500 messages per second on a 
week long session.

On Sep 29, 2004, at 8:30 PM, Caleb Epstein 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 Tue, 28 Sep 2004 12:07:55 -0500, Oren Miller 
> <or...@qu...> wrote:
>
>> QuickFIX has no limitation on the number of messages it can handle,
>
> Well, technically it does.  The MessageStore uses int as a key, so
> you'd need to do a sequence reset at numeric_limits<int>::max().
>
> -- 
> Caleb Epstein
> cal...@gm...
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on 
> ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give 
> us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out 
> more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

Re: [Quickfix-developers] Threading issue

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

On Tue, 28 Sep 2004 12:07:55 -0500, Oren Miller <or...@qu...> wrote:

> QuickFIX has no limitation on the number of messages it can handle,

Well, technically it does.  The MessageStore uses int as a key, so
you'd need to do a sequence reset at numeric_limits<int>::max().

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

Re: [Quickfix-developers] Unexpected Signal : EXCEPTION_ACCESS_VIOLATION (fwd)

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

Andrew,

Do you know the string that is being passed into setString?

--oren

On Sep 28, 2004, at 10:54 AM, Andrew Munn 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
>
>
> QuickFIX is crashing with this error from the JVM.  Can someone tell 
> me if
> this has been fixed in SF?  I'm using 1.9.0.
>
> Thanks,
> Andrew
>
>
>
>
> 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 - 0x2CBDF000         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
> 0x2CBE0000 - 0x2CBEF000         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
> 0x2CC50000 - 0x2CD5F000         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
> 0x2CD60000 - 0x2CDB0000         
> 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
> 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 8777K [0x10010000, 0x10a00000,
> 0x11d9000
> 0)
>   eden space 8256K,  99% used [0x10010000, 0x1081fff8, 0x10820000)
>   from space 960K,  54% used [0x10820000, 0x108a2590, 0x10910000)
>   to   space 960K,   0% used [0x10910000, 0x10910000, 0x10a00000)
>  tenured generation   total 121024K, used 23942K [0x11d90000, 
> 0x193c0000,
> 0x2801
> 0000)
>    the space 121024K,  19% used [0x11d90000, 0x134f1a20, 0x134f1c00,
> 0x193c0000)
>
>  compacting perm gen  total 15616K, used 15578K [0x28010000, 
> 0x28f50000,
> 0x2c010
> 000)
>    the space 15616K,  99% used [0x28010000, 0x28f468c0, 0x28f46a00,
> 0x28f50000)
>
> Local Time = Tue Sep 28 10:15:12 2004
> Elapsed Time = 61
> #
> # 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_pid1148.log.
> # Please refer to the file for further information.
> #
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

Re: [Quickfix-developers] potential infinite loop in QuickFIX Message constructor

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

Yeah, in that case Yihu's patch covers this case as well.

--oren

On Sep 29, 2004, at 10:14 AM, Brendan B. Boerner wrote:

> Oren,
>
> The following produces it for me (replace endlines w/^As, the message
> should end with the 'abc' following tag10=171).
>
> The CRC/Lengths won't be accurate as I've changed some of the fields
> but will repro the problem.
>
> This is w/QF v1.8.0.
>
> Regards,
> Brendan
>
> 8=FIX.4.2
> 9=302
> 35=S
> 34=5130
> 49=TARGET
> 52=20040901-20:44:54
> 56=SENDER
> 15=USD
> 40=C
> 55=USD/CAD
> 60=20040901-20:44:54
> 64=20040902
> 117=ABC
> 131=16
> 132=1.3072
> 133=1.3076
> 134=100000.000000
> 135=100000.000000
> 167=FOR
> 188=1.3072
> 189=0.00
> 190=1.3076
> 191=0.00
> 301=0
> 647=0.000000
> 648=0.000000
> 10=171
> abc
>
>
>
>> -----Original Message-----
>> From: Oren Miller [mailto:or...@qu...]
>> Sent: Wednesday, September 29, 2004 8:33 AM
>> To: br...@ka...
>> Cc: qui...@li...; Yih...@re...
>> Subject: Re: [Quickfix-developers] potential infinite loop in QuickFIX
>> Message constructor
>>
>>
>> Brendan,
>>
>> I wrote a test case for this, but have not been able to duplicate the
>> behavior.  Do you have an example of a string that would cause this?
>
>

RE: [Quickfix-developers] potential infinite loop in QuickFIX Message constructor

[Brendan B. B. <br...@ka...>]

Oren,

The following produces it for me (replace endlines w/^As, the message
should end with the 'abc' following tag10=171).

The CRC/Lengths won't be accurate as I've changed some of the fields
but will repro the problem.

This is w/QF v1.8.0.

Regards,
Brendan

8=FIX.4.2
9=302
35=S
34=5130
49=TARGET
52=20040901-20:44:54
56=SENDER
15=USD
40=C
55=USD/CAD
60=20040901-20:44:54
64=20040902
117=ABC
131=16
132=1.3072
133=1.3076
134=100000.000000
135=100000.000000
167=FOR
188=1.3072
189=0.00
190=1.3076
191=0.00
301=0
647=0.000000
648=0.000000
10=171
abc



> -----Original Message-----
> From: Oren Miller [mailto:or...@qu...]
> Sent: Wednesday, September 29, 2004 8:33 AM
> To: br...@ka...
> Cc: qui...@li...; Yih...@re...
> Subject: Re: [Quickfix-developers] potential infinite loop in QuickFIX
> Message constructor
> 
> 
> Brendan,
> 
> I wrote a test case for this, but have not been able to duplicate the 
> behavior.  Do you have an example of a string that would cause this?

Re: [Quickfix-developers] potential infinite loop in QuickFIX Message constructor

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

Brendan,

I wrote a test case for this, but have not been able to duplicate the 
behavior.  Do you have an example of a string that would cause this?

--oren

On Sep 28, 2004, at 5:51 PM, Brendan B. Boerner 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
>
> Yihu,
>
> You might want to see if my fix in Message::setString(...)  for a
> related problem works as well.
>
> The message I sent on 9/2 follows.
>
> Regards,
> Brendan
>
> Hi,
>
> Suppose a FIX::Message is constructed from a string and suppose the
> string is a concatenation of two FIX messages (e.g. suppose you're
> reading from a log of FIX msgs which somehow was corrupted).
>
> In Message::setString(const std::string, bool, const DataDictionary
> *), w/o the two lines I've added below, this will be an infinite loop
> as pos will increase through the massage which corresponds to the
> 'first' message and then reset to a low value when it reaches the
> 'second' message in the string i.e.  pos will never be >=
> string.size().
>
>   while ( pos < string.size() )
>   {
>     FieldBase field = extractField( string, pos, pDataDictionary );
>     // Begin brendan, 9/2/04
>     if (pos < pos2) throw InvalidMessage();
>     else pos2 = pos;
>     // End brendan, 9/2/04
>
>     if ( count < 3 && headerOrder[ count++ ] != field.getField() )
>       if ( doValidation ) throw InvalidMessage();
>     ...
>   }
>
> Regards,
> Brendan
>
>
>
>
>> Message: 2
>> Date: Mon, 27 Sep 2004 16:58:18 -0400
>> From: Yihu Fang <Yih...@re...>
>> To: Oren Miller <or...@qu...>,
>>  qui...@li...
>> Subject: [Quickfix-developers] potential infinite loop in
>> QuickFIX Message constructor
>>
>> This is a multi-part message in MIME format.
>>
>> ------_=_NextPart_001_01C4A4D4.B7119FAC
>> Content-Type: text/plain; charset="us-ascii"
>> Content-Transfer-Encoding: quoted-printable
>>
>> Oren,
>>
>> =20
>>
>> There is a bug in QuickFIX Message constructor which may exists in all
>> versions. An ill-formatted FIX message can let the constructor run 
>> into
>> a tight infinite loop. If the FIX message has an extra white space at
>> the end of trailer "8=3DFIX.4.0<SOH>...<SOH>10=3Dxxx<SOH> ", or any 
>> extra
>> characters in that matter, the constructor calls setString() and 
>> results
>> in an infinite loop.
>>
>> =20
>>
>> The fix is to check the value of the equalSign and throw an exception 
>> if
>> not found. The diff of current CVS Message.cpp should be:
>>
>> =20
>>
>> 560a561,562
>>
>>>   if (equalSign =3D=3D std::string::npos)
>>
>>>     throw InvalidMessage();
>>
>> =20
>>
>> Thanks.
>>
>> =20
>>
>> -Yihu
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on 
> ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give 
> us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out 
> more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

RE: [Quickfix-developers] potential infinite loop in QuickFIX Message constructor

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

Brendan,

I don't think that a string of concatenation of multiple FIX messages in
Message constructor will cause looping after Oren's patch for trailing
chars. Any missed <SOH> or "=3D" will throw an exception. And the
validation at the end of setString() will throw an exception if multiple
FIX messages concatenated together because FIX bodylength field will not
be able to account the extra length in the string.

Regards,

-Yihu

-----Original Message-----
From: qui...@li...
[mailto:qui...@li...] On Behalf Of
Brendan B. Boerner
Sent: Tuesday, September 28, 2004 6:51 PM
To: Yihu Fang
Cc: qui...@li...
Subject: RE: [Quickfix-developers] potential infinite loop in QuickFIX
Message constructor

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

Yihu,

You might want to see if my fix in Message::setString(...)  for a
related problem works as well.

The message I sent on 9/2 follows.

Regards,
Brendan

Hi,

Suppose a FIX::Message is constructed from a string and suppose the
string is a concatenation of two FIX messages (e.g. suppose you're
reading from a log of FIX msgs which somehow was corrupted).

In Message::setString(const std::string, bool, const DataDictionary
*), w/o the two lines I've added below, this will be an infinite loop
as pos will increase through the massage which corresponds to the
'first' message and then reset to a low value when it reaches the
'second' message in the string i.e.  pos will never be >=3D
string.size().

  while ( pos < string.size() )
  {
    FieldBase field =3D extractField( string, pos, pDataDictionary );
    // Begin brendan, 9/2/04
    if (pos < pos2) throw InvalidMessage();
    else pos2 =3D pos;
    // End brendan, 9/2/04

    if ( count < 3 && headerOrder[ count++ ] !=3D field.getField() )
      if ( doValidation ) throw InvalidMessage();
    ...
  }

Regards,
Brendan




> Message: 2
> Date: Mon, 27 Sep 2004 16:58:18 -0400
> From: Yihu Fang <Yih...@re...>
> To: Oren Miller <or...@qu...>,
>  qui...@li...
> Subject: [Quickfix-developers] potential infinite loop in=20
> QuickFIX Message constructor
>=20
> This is a multi-part message in MIME format.
>=20
> ------_=3D_NextPart_001_01C4A4D4.B7119FAC
> Content-Type: text/plain; charset=3D"us-ascii"
> Content-Transfer-Encoding: quoted-printable
>=20
> Oren,
>=20
> =3D20
>=20
> There is a bug in QuickFIX Message constructor which may exists in all
> versions. An ill-formatted FIX message can let the constructor run
into
> a tight infinite loop. If the FIX message has an extra white space at
> the end of trailer "8=3D3DFIX.4.0<SOH>...<SOH>10=3D3Dxxx<SOH> ", or any
extra
> characters in that matter, the constructor calls setString() and
results
> in an infinite loop.
>=20
> =3D20
>=20
> The fix is to check the value of the equalSign and throw an exception
if
> not found. The diff of current CVS Message.cpp should be:
>=20
> =3D20
>=20
> 560a561,562
>=20
> >   if (equalSign =3D3D=3D3D std::string::npos)
>=20
> >     throw InvalidMessage();
>=20
> =3D20
>=20
> Thanks.
>=20
> =3D20
>=20
> -Yihu


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give
us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out
more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers



-----------------------------------------------------------------
        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] potential infinite loop in QuickFIX Message constructor

[Brendan B. B. <br...@ka...>]

Yihu,

You might want to see if my fix in Message::setString(...)  for a
related problem works as well.

The message I sent on 9/2 follows.

Regards,
Brendan

Hi,

Suppose a FIX::Message is constructed from a string and suppose the
string is a concatenation of two FIX messages (e.g. suppose you're
reading from a log of FIX msgs which somehow was corrupted).

In Message::setString(const std::string, bool, const DataDictionary
*), w/o the two lines I've added below, this will be an infinite loop
as pos will increase through the massage which corresponds to the
'first' message and then reset to a low value when it reaches the
'second' message in the string i.e.  pos will never be >=
string.size().

  while ( pos < string.size() )
  {
    FieldBase field = extractField( string, pos, pDataDictionary );
    // Begin brendan, 9/2/04
    if (pos < pos2) throw InvalidMessage();
    else pos2 = pos;
    // End brendan, 9/2/04

    if ( count < 3 && headerOrder[ count++ ] != field.getField() )
      if ( doValidation ) throw InvalidMessage();
    ...
  }

Regards,
Brendan




> Message: 2
> Date: Mon, 27 Sep 2004 16:58:18 -0400
> From: Yihu Fang <Yih...@re...>
> To: Oren Miller <or...@qu...>,
>  qui...@li...
> Subject: [Quickfix-developers] potential infinite loop in 
> QuickFIX Message constructor
> 
> This is a multi-part message in MIME format.
> 
> ------_=_NextPart_001_01C4A4D4.B7119FAC
> Content-Type: text/plain; charset="us-ascii"
> Content-Transfer-Encoding: quoted-printable
> 
> Oren,
> 
> =20
> 
> There is a bug in QuickFIX Message constructor which may exists in all
> versions. An ill-formatted FIX message can let the constructor run into
> a tight infinite loop. If the FIX message has an extra white space at
> the end of trailer "8=3DFIX.4.0<SOH>...<SOH>10=3Dxxx<SOH> ", or any extra
> characters in that matter, the constructor calls setString() and results
> in an infinite loop.
> 
> =20
> 
> The fix is to check the value of the equalSign and throw an exception if
> not found. The diff of current CVS Message.cpp should be:
> 
> =20
> 
> 560a561,562
> 
> >   if (equalSign =3D=3D std::string::npos)
> 
> >     throw InvalidMessage();
> 
> =20
> 
> Thanks.
> 
> =20
> 
> -Yihu

Re: [Quickfix-developers] Threading issue

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

Slight correction on my previous post.  To use the 
SynchronizedApplication, continue to inherit from Application, but you 
must pass the Initiator a SynchronizedApplication which wraps around 
you application.

i.e.
// inherits from FIX::Application
MyApplication application;
FIX::SynchronizedApplication syncrhonizedApplication( application );
// pass in synchronizedApplication to ThreadedSocketInitiator in place 
of application

On Sep 28, 2004, at 11:12 AM, Sharma Himanshu 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 am using QuickFIX v1.8.0. The configuration file is defining more 
> that one session. The session's socket initiator class 
> ThreadedSocketInitiator.
>
> I have overloaded the fromApp(). Here I am trapping the messages 
> coming from counterparty engine and pushing into a queue.
>
> void myclass::fromApp(const Message & msg, const SessionID & session)
> {
>    receive(msg);
> }
>
> ...
>
> void receive(Message& msg)
> {
>     //add to queue.
>    add_queue(msg);
> }
>
> Question:
>
> 1. Is there any reason to assume this would cause any threading 
> issues? Is fromApp() thread-safe?
>
> 2. Is there any limitation in quickfix that would limit the number of 
> messages it can handle?
>
> Thanks in advance,
> Himanshu
>
> _________________________________________________________________
> Seized by wanderlust? http://www.msn.co.in/Travel/ Have the best 
> vacation ever.
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

Re: [Quickfix-developers] Threading issue

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

You do have to synchronize.  But, if you inherit your application class 
from SynchronizedApplication, instead of directly from Application, 
then the synchronization will be done for you making those methods 
effectively thread safe.  The limitation of course is that you can only 
process one message at a time, and you may be locking for longer then 
is optimal.  But if you are just sticking them onto a queue, this is 
probably what you want.

QuickFIX has no limitation on the number of messages it can handle, 
barring it doesn't run out of sequence numbers.  Technically some 
versions of the spec say number should be reset at 99999, but I think 
this is probably a relic of lower volume days.  So currently we allow 
sequence numbers to go up as high as possible.  I don't know of any 
case where this has been a problem and don't know whether or not other 
engines have chosen to implement the 99999 rule.

--oren

On Sep 28, 2004, at 11:12 AM, Sharma Himanshu 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 am using QuickFIX v1.8.0. The configuration file is defining more 
> that one session. The session's socket initiator class 
> ThreadedSocketInitiator.
>
> I have overloaded the fromApp(). Here I am trapping the messages 
> coming from counterparty engine and pushing into a queue.
>
> void myclass::fromApp(const Message & msg, const SessionID & session)
> {
>    receive(msg);
> }
>
> ...
>
> void receive(Message& msg)
> {
>     //add to queue.
>    add_queue(msg);
> }
>
> Question:
>
> 1. Is there any reason to assume this would cause any threading 
> issues? Is fromApp() thread-safe?
>
> 2. Is there any limitation in quickfix that would limit the number of 
> messages it can handle?
>
> Thanks in advance,
> Himanshu
>
> _________________________________________________________________
> Seized by wanderlust? http://www.msn.co.in/Travel/ Have the best 
> vacation ever.
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

[Quickfix-developers] Re: potential infinite loop in QuickFIX Message constructor

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

This has been checked in with an accompanying test case.

--oren

On Sep 27, 2004, at 3:58 PM, Yihu Fang wrote:

> Oren,
>
> =A0
>
> There is a bug in QuickFIX Message constructor which may exists in all=20=

> versions. An ill-formatted FIX message can let the constructor run=20
> into a tight infinite loop. If the FIX message has an extra white=20
> space at the end of trailer =938=3DFIX.4.0<SOH>=85<SOH>10=3Dxxx<SOH> =
=93, or any=20
> extra characters in that matter, the constructor calls setString() and=20=

> results in an infinite loop.
>
> =A0
>
> The fix is to check the value of the equalSign and throw an exception=20=

> if not found. The diff of current CVS Message.cpp should be:
>
> =A0
>
> 560a561,562
>
> >=A0=A0 if (equalSign =3D=3D std::string::npos)
>
> >=A0=A0=A0=A0 throw InvalidMessage();
>
> =A0
>
> Thanks.
>
> =A0
>
> -Yihu
>
>
>  -----------------------------------------------------------------
>  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.
> =20=

[Quickfix-developers] Threading issue

[Sharma H. <sha...@ho...>]

Hi,

I am using QuickFIX v1.8.0. The configuration file is defining more that one 
session. The session's socket initiator class ThreadedSocketInitiator.

I have overloaded the fromApp(). Here I am trapping the messages coming from 
counterparty engine and pushing into a queue.

void myclass::fromApp(const Message & msg, const SessionID & session)
{
    receive(msg);
}

...

void receive(Message& msg)
{
     //add to queue.
    add_queue(msg);
}

Question:

1. Is there any reason to assume this would cause any threading issues? Is 
fromApp() thread-safe?

2. Is there any limitation in quickfix that would limit the number of 
messages it can handle?

Thanks in advance,
Himanshu

_________________________________________________________________
Seized by wanderlust? http://www.msn.co.in/Travel/ Have the best vacation 
ever.

[Quickfix-developers] Unexpected Signal : EXCEPTION_ACCESS_VIOLATION (fwd)

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

QuickFIX is crashing with this error from the JVM.  Can someone tell me if 
this has been fixed in SF?  I'm using 1.9.0.

Thanks,
Andrew




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 - 0x2CBDF000         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
0x2CBE0000 - 0x2CBEF000         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
0x2CC50000 - 0x2CD5F000         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
0x2CD60000 - 0x2CDB0000         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
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 8777K [0x10010000, 0x10a00000, 
0x11d9000
0)
  eden space 8256K,  99% used [0x10010000, 0x1081fff8, 0x10820000)
  from space 960K,  54% used [0x10820000, 0x108a2590, 0x10910000)
  to   space 960K,   0% used [0x10910000, 0x10910000, 0x10a00000)
 tenured generation   total 121024K, used 23942K [0x11d90000, 0x193c0000, 
0x2801
0000)
   the space 121024K,  19% used [0x11d90000, 0x134f1a20, 0x134f1c00, 
0x193c0000)

 compacting perm gen  total 15616K, used 15578K [0x28010000, 0x28f50000, 
0x2c010
000)
   the space 15616K,  99% used [0x28010000, 0x28f468c0, 0x28f46a00, 
0x28f50000)

Local Time = Tue Sep 28 10:15:12 2004
Elapsed Time = 61
#
# 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_pid1148.log.
# Please refer to the file for further information.
#

Re: [Quickfix-developers] CME and week long session

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

On Tue, 28 Sep 2004 10:05:27 +0200, Franco Sabini <f.s...@fi...> wrote:

> (I wrote my own Store to use a Sybase database trough a RendezVous adapter.)
> 
> The mktime conversion seems to place the correct value in tm_wday.
> This morning I didn't get any session reset and I'm still using the session
> begun yestarday.

Note that mktime expects the "struct tm" you pass it to be expressed
in local time, but QuickFIX UtcTimeStamps use GMT as their basis.  I
think this is just a timezone conversion issue.  You need to express
your start and end times (and store your session creation time) in
GMT, not local time.

Since you've written your own store (and decoupled it from the
application with a messaging middleware) there are several different
places where you may be converting time formats so its really hard to
tell where the problem lies precisely, but I think the code you pasted
is just working around another problem.

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

RE: [Quickfix-developers] CME and week long session

[Franco S. <f.s...@fi...>]

Hi,
I find out on friday what could be my problem: it seems that the conversion
between
string and UtcTimeStamp doesn't work properly:
20040923-08:00:00 (thursday) is converted as week day (tm_wday field) 6.
Same value is assigned to UtcTimeStamp() (on friday) so the method
isSessionTime compute wrong
values here:
    int time1Range = time1.getWeekDay() - startDay;
    int time2Range = time2.getWeekDay() - startDay;

Could this lead to a session reset ?

Actually I solved the problem with an extra conversion in populateCache() :

      std::string sqlTime =_sqlTime;
      UtcTimeStamp result = UtcTimeStampConvertor::convert(
sqlTime.c_str() ) ;
      tm *tmstmp=static_cast<tm*>(result);
      time_t _tmstmp=mktime(tmstmp);
      UtcTimeStamp _result(_tmstmp);
      m_cache.setCreationTime( _result );

(I wrote my own Store to use a Sybase database trough a RendezVous adapter.)

The mktime conversion seems to place the correct value in tm_wday.
This morning I didn't get any session reset and I'm still using the session
begun
yestarday.

Thanks again,

Franco

-----Original Message-----
From: qui...@li...
[mailto:qui...@li...]On Behalf Of Jon
Dahl
Sent: Monday, September 27, 2004 5:27 PM
To: qui...@li...
Cc: f.s...@fi...
Subject: Re: [Quickfix-developers] CME and week long session


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

Franco,

Can you send a few of the messages you are receiving from the CME gateway
during the session reset?

Preferably, when you send a logon(35=A) message to the gateway and the
response message you receive.

Thanks,

-jd-

> 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 all,
> I'm having some trouble with the famouse week long CME's sessions. I'm
> using quickfix 1.9.1 with this cfg:
> [DEFAULT]
> ConnectionType=initiator
> HeartBtInt=30
> FileStorePath=store
> FileLogPath=logs
> StartTime=06:00:00
> EndTime=23:00:00
> StartDay=mo
> EndDay=fr
> UseDataDictionary=Y
> DataDictionary=/home/sviluppo/LM/CME_CC/xml/fix42_cme.xml
> ValidateFieldsOutOfOrder=N
> ValidateFieldsHaveValues=N
> SocketConnectHost=10.1.56.75
> SocketConnectPort=9303
> MaxLatency=36000
> ResetOnDisconnect=N
> ResetOnLogut=N
>
>
> I get a session reset every day when I perform the first login to the
> market, Am I missing something ?
>
> Thanks,
>
> Franco Sabini
> FinecoBank S.p.A
> Via M. D'Aviano 5
> 20131 Milano
> Tel: +39 02 2887 2447
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers


--





-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers

[Quickfix-developers] potential infinite loop in QuickFIX Message constructor

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

Oren,

=20

There is a bug in QuickFIX Message constructor which may exists in all
versions. An ill-formatted FIX message can let the constructor run into
a tight infinite loop. If the FIX message has an extra white space at
the end of trailer "8=3DFIX.4.0<SOH>...<SOH>10=3Dxxx<SOH> ", or any extra
characters in that matter, the constructor calls setString() and results
in an infinite loop.

=20

The fix is to check the value of the equalSign and throw an exception if
not found. The diff of current CVS Message.cpp should be:

=20

560a561,562

>   if (equalSign =3D=3D std::string::npos)

>     throw InvalidMessage();

=20

Thanks.

=20

-Yihu



-----------------------------------------------------------------
        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] CME and week long session

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

Franco,

Can you send a few of the messages you are receiving from the CME gateway
during the session reset?

Preferably, when you send a logon(35=A) message to the gateway and the
response message you receive.

Thanks,

-jd-

> 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 all,
> I'm having some trouble with the famouse week long CME's sessions. I'm
> using quickfix 1.9.1 with this cfg:
> [DEFAULT]
> ConnectionType=initiator
> HeartBtInt=30
> FileStorePath=store
> FileLogPath=logs
> StartTime=06:00:00
> EndTime=23:00:00
> StartDay=mo
> EndDay=fr
> UseDataDictionary=Y
> DataDictionary=/home/sviluppo/LM/CME_CC/xml/fix42_cme.xml
> ValidateFieldsOutOfOrder=N
> ValidateFieldsHaveValues=N
> SocketConnectHost=10.1.56.75
> SocketConnectPort=9303
> MaxLatency=36000
> ResetOnDisconnect=N
> ResetOnLogut=N
>
>
> I get a session reset every day when I perform the first login to the
> market, Am I missing something ?
>
> Thanks,
>
> Franco Sabini
> FinecoBank S.p.A
> Via M. D'Aviano 5
> 20131 Milano
> Tel: +39 02 2887 2447
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers


-- 

[Quickfix-developers] CME and week long session

[Franco S. <f.s...@fi...>]

Hi all,
I'm having some trouble with the famouse week long CME's sessions.
I'm using quickfix 1.9.1 with this cfg:
[DEFAULT]
ConnectionType=initiator
HeartBtInt=30
FileStorePath=store
FileLogPath=logs
StartTime=06:00:00
EndTime=23:00:00
StartDay=mo
EndDay=fr
UseDataDictionary=Y
DataDictionary=/home/sviluppo/LM/CME_CC/xml/fix42_cme.xml
ValidateFieldsOutOfOrder=N
ValidateFieldsHaveValues=N
SocketConnectHost=10.1.56.75
SocketConnectPort=9303
MaxLatency=36000
ResetOnDisconnect=N
ResetOnLogut=N


I get a session reset every day when I perform the first login to the
market, Am I missing something ?

Thanks,

Franco Sabini
FinecoBank S.p.A
Via M. D'Aviano 5
20131 Milano
Tel: +39 02 2887 2447

[Quickfix-developers] FieldConvertError not caught in Session::insertSendingTime()

[Brendan B. B. <br...@ka...>]

Hi,

I have an app running on Linux which submits some
FIX42::QuoteRequests and accepts any incoming FIX42::Quotes.

Periodically I've noticed that the app will terminate due to an
uncaught exception.

I enabled ENABLE_CALLSTACK and found this after the last occurence:

thread(1026):N3FIX17FieldConvertErrorE: Could not convert field
  at time_gmtime(Utility.cpp:282)
  at Session::insertSendingTime(Session.cpp:81)
  at Session::fill(Session.cpp:98)
  at Session::generateHeartbeat(Session.cpp:602)
  at Session::next(Session.cpp:112)
  at SocketConnection::onTimeout(SocketConnection.cpp:214)
  at SocketInitiator::onTimeout(SocketInitiator.cpp:189)
  at ConnectorWrapper::onTimeout(SocketConnector.cpp:76)
  at SocketMonitor::block(SocketMonitor.cpp:141)
  at SocketConnector::block(SocketConnector.cpp:120)
  at SocketInitiator::onStart(SocketInitiator.cpp:69)
  at Initiator::startThread(Initiator.cpp:217)

Debugging through the CallStack code I think the
"time_gmtime(Utility.cpp:282)" is in error - it didn't abend but
wasn't removed from the CallStack before calling:

    UtcTimeStampConvertor::convert(now, m_millisecondsInTimeStamp)

(I didn't have MillisecondsInTimeStamp=N in my settings file).

UtcTimeStampConvertor::convert(UtcTimeStamp &, bool) throws a
FieldConvertError if strftime() produces an unexpected result or if
adding the millsecs doesn't result in 3 chars.

I've added some debugging couts << but wouldn't you know, the problem
hasn't reproduced since :-(.

I can't see why UtcTimeStampConvertor::convert() should be throwing a
convert error for current time (unless somehow m_ms > 1000?), but it
might be advisable to catch the FieldConvertError in
Session::insertSendingTime(Header &) and retry...

Regards,
Brendan

[Quickfix-developers] Bodylength calculation with a FIX44 message including a sub-group

[Bill R. Hr. <bil...@ra...>]

The following message

8=FIX.4.4!9=528!35=8!49=VTX!56=XXXXX!11=M/2691122!150=B!39=B!37=7-65551-V!19
8=O/2715468!527=1000343M000027B1!336=EBS-2!625=EBS-7!453=2!448=3112!447=D!45
2=1!802=1!523=UBSZHM12!803=3!448=18207!447=D!452=11!526=O/2715468!17=1000343
M000027B1-1V-1!636=Y!1=AU!581=1!48=CH0016440353!22=4!207=XVTX!107=EMS-CHEMIE
N!15=CHF!30=XVTX!54=1!151=0.000000!14=300!6=102.300000!32=300!31=102.300000!
381=30690.000000!29=1!58=CHF
30720.00;!75=20040922-10:00:17!118=30690.000000!119=30690.000000!64=20040927
-00:00:00!120=CHF!155=1.000000!156=M!60=20040922-00:00:00!10=103!

triggers the exception "Invalid message: Expected BodyLength=534, Recieved
BodyLength=528". Counting the length manually gives the same result, the
length is 528.

My application receives the FIX message from a internal system in a string
and validates it with QuickFIX, e.g.
    FIX::Message msg(p_content, dict);
Where p_content contains the message as a string. 



After some checking I believe that the usage a the subgroup (see following
structure out of FIX44.xml) is the cause.

 <component name="Parties">
      <group name="NoPartyIDs" required="N">
        <field name="PartyID" required="N" />
        <field name="PartyIDSource" required="N" />
        <field name="PartyRole" required="N" />
        <group name="NoPartySubIDs" required="N">
          <field name="PartySubID" required="N" />
          <field name="PartySubIDType" required="N" />
        </group>
      </group>
    </component>

The function calculateLength seems to count the length of field 802
(NoPartySubIds) twice (which results in a total length of by 6 bytes).
But I'm not sure about how to fix FieldMap::calculateLength.

Regards
Robert


PS: The message checksum doesn't compute as I changed tag 56 and replace !
mentally with \001...

Re: [Quickfix-developers] Acceptor App High Number Of Socket Drops

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

Are you sure that 2048 is enough?  You didn't really provide these 
details, but assuming you are using the FileLog and FileStore, that's 7 
descriptors per session just for those files alone, or 1,953.  Doesn't 
leave you enough for the sockets for sure.  When you say it works at 
103, is that to say that 104 doesn't work?  What do you get from 'ls -l 
/proc/<pid of quickfix app>/fd | wc -l'?

If you are using a FileStore, it's pretty useless to do so since you 
have ResetOnDisconnect and ResetOnLogout set to Y.  You might want to 
switch to a memory store (will increase memory usage).  Or if this is 
some sort of high speed market data line (looks like it might be based 
on this configuration), a NullStore may be an option.

--oren

On Sep 21, 2004, at 10:19 AM, Jon Dahl 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
>
> We are doing some stress testing with our quickfix implementation and 
> have
> come upon a snag.
>
> We loaded up 279 SenderCompID's in our accpetor app config file. We 
> also
> have increased the ulimit for our shell account to 2048. The app 
> starts up
> fine - no errors. However, our clients can't sustain a connection. The
> logs show the socket connection is being made, however, it is 
> immediately
> dropped and netstat shows the socket connections in a CLOSED_WAIT 
> status.
>
> What's interesting is if we lower the SenderCompID's to 103 or less, 
> the
> clients can connect fine.
>
> Specs:
> RHAS 2.1
> g++ 3.0.7
> QF 1.7.0 in Production, 1.9.0 in QA
> ResetOnDisconnect=Y
> ResetOnLogout=Y
> UseDataDictionary=N
>
> Any help would be appreciated.
>
> Thanks,
>
> -jd-
>
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

[Quickfix-developers] Acceptor App High Number Of Socket Drops

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

We are doing some stress testing with our quickfix implementation and have
come upon a snag.

We loaded up 279 SenderCompID's in our accpetor app config file. We also
have increased the ulimit for our shell account to 2048. The app starts up
fine - no errors. However, our clients can't sustain a connection. The
logs show the socket connection is being made, however, it is immediately
dropped and netstat shows the socket connections in a CLOSED_WAIT status.

What's interesting is if we lower the SenderCompID's to 103 or less, the
clients can connect fine.

Specs:
RHAS 2.1
g++ 3.0.7
QF 1.7.0 in Production, 1.9.0 in QA
ResetOnDisconnect=Y
ResetOnLogout=Y
UseDataDictionary=N

Any help would be appreciated.

Thanks,

-jd-

Re: [Quickfix-developers] QuickFIX sending extra Logouts?

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

This patch seems to fix the problem.  I'm no longer seeing the flood
of logout messages getting generated.

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

Re: [Quickfix-developers] QuickFIX sending extra Logouts?

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

Caleb,

I think this may be a simple fix.  In Session::next(), try changing 
this code block:

         if( !m_state.sentLogout() )
           m_state.onEvent( "Initiated logout request" );
         generateLogout();

to this:

         if( !m_state.sentLogout() )
         {
           m_state.onEvent( "Initiated logout request" );
           generateLogout();
         }

Let me know how your tests turn out after making this change.

--oren

On Sep 20, 2004, at 4:51 PM, Caleb Epstein wrote:

> I'm working on a Berkeley DB-backed MessageStore, and am
> torture-testing it with some small applications.  I've run across some
> behavior that I think illustrates a bug in QuickFIX.
>
> I have a slightly modified version of the "executor" example app as my
> FIX server.  I modified it to fill MKT orders (just sends a hard-coded
> price of 1) and send an ACK before every execution report.
> Additionally, I installed a signal handler to catch SIGINT and SIGTERM
> and do a clean shutdown (the "wait" function just detects that the
> signal was caught and exits now).
>
> As my client, I wrote a small Application which just reads orders from
> a text file and sends them to the server and produces some benchmark
> timings.
>
> These are both working fine.  Now I'm trying to break things (to test
> the robustness of both QuickFIX and Berkeley DB) and see how well they
> can recover.
>
> On the client side, I have my application drop its connection as soon
> as it is done sending orders (I am just returning from
> Application::run).  I'm trying to cause messages to be "queued up" on
> the sending side so they will need to retransmitted on the next
> connection, but my client application ends up blocking until all the
> messages in response to its order flow have been received.  This is
> fine, but while it is blocking (after Application::run has returned),
> it appears to send a new Logout message for each message it receives
> from the executor, and this causes the executor to log the message
> "Logon state is not valid for message" for each of these.
>
> I am able to create a similar scenario by interrupting the executor
> when it is in the middle of receiving a number of messages from the
> client.  In this case, I shut down the SocketAcceptor and the executor
> ends up sending extra Logout messages to the client.  It looks like
> the same problem, just reversed.
>
> This scenario is reproducible every time, even if I use the FileStore
> instead of my Berkeley DB MessageStore.  I'm attaching some logs that
> illustrate it.  The directory "logs.executor-killed" is the first
> scenario and "logs.client-exited" is the second.  Please let me know
> if more info is needed to help debug this.
>
> -- 
> Caleb Epstein
> cal...@gm...
> <extra-logouts.tar.gz>

[Quickfix-developers] Re: QuickFIX sending extra Logouts?

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

A bug report has been filed: 
http://www.quickfixengine.org/bugtracker/bug.php?op=show&bugid=8

We'll take a look at this.

--oren

On Sep 20, 2004, at 4:51 PM, Caleb Epstein wrote:

> I'm working on a Berkeley DB-backed MessageStore, and am
> torture-testing it with some small applications.  I've run across some
> behavior that I think illustrates a bug in QuickFIX.
>
> I have a slightly modified version of the "executor" example app as my
> FIX server.  I modified it to fill MKT orders (just sends a hard-coded
> price of 1) and send an ACK before every execution report.
> Additionally, I installed a signal handler to catch SIGINT and SIGTERM
> and do a clean shutdown (the "wait" function just detects that the
> signal was caught and exits now).
>
> As my client, I wrote a small Application which just reads orders from
> a text file and sends them to the server and produces some benchmark
> timings.
>
> These are both working fine.  Now I'm trying to break things (to test
> the robustness of both QuickFIX and Berkeley DB) and see how well they
> can recover.
>
> On the client side, I have my application drop its connection as soon
> as it is done sending orders (I am just returning from
> Application::run).  I'm trying to cause messages to be "queued up" on
> the sending side so they will need to retransmitted on the next
> connection, but my client application ends up blocking until all the
> messages in response to its order flow have been received.  This is
> fine, but while it is blocking (after Application::run has returned),
> it appears to send a new Logout message for each message it receives
> from the executor, and this causes the executor to log the message
> "Logon state is not valid for message" for each of these.
>
> I am able to create a similar scenario by interrupting the executor
> when it is in the middle of receiving a number of messages from the
> client.  In this case, I shut down the SocketAcceptor and the executor
> ends up sending extra Logout messages to the client.  It looks like
> the same problem, just reversed.
>
> This scenario is reproducible every time, even if I use the FileStore
> instead of my Berkeley DB MessageStore.  I'm attaching some logs that
> illustrate it.  The directory "logs.executor-killed" is the first
> scenario and "logs.client-exited" is the second.  Please let me know
> if more info is needed to help debug this.
>
> -- 
> Caleb Epstein
> cal...@gm...
> <extra-logouts.tar.gz>