quickfix-developers Mailing List for QuickFIX (Page 223)
Brought to you by:
orenmnero
Menu
▾
▴
quickfix-developers — QuickFIX developers forum
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
|
Feb
(5) |
Mar
(16) |
Apr
(15) |
May
(17) |
Jun
(33) |
Jul
(35) |
Aug
(34) |
Sep
(19) |
Oct
(40) |
Nov
(51) |
Dec
(43) |
| 2003 |
Jan
(45) |
Feb
(79) |
Mar
(124) |
Apr
(121) |
May
(132) |
Jun
(77) |
Jul
(110) |
Aug
(57) |
Sep
(48) |
Oct
(83) |
Nov
(60) |
Dec
(40) |
| 2004 |
Jan
(67) |
Feb
(72) |
Mar
(74) |
Apr
(87) |
May
(70) |
Jun
(96) |
Jul
(75) |
Aug
(147) |
Sep
(128) |
Oct
(83) |
Nov
(67) |
Dec
(42) |
| 2005 |
Jan
(110) |
Feb
(84) |
Mar
(68) |
Apr
(55) |
May
(51) |
Jun
(192) |
Jul
(111) |
Aug
(100) |
Sep
(79) |
Oct
(127) |
Nov
(73) |
Dec
(112) |
| 2006 |
Jan
(95) |
Feb
(120) |
Mar
(138) |
Apr
(127) |
May
(124) |
Jun
(97) |
Jul
(103) |
Aug
(88) |
Sep
(138) |
Oct
(91) |
Nov
(112) |
Dec
(57) |
| 2007 |
Jan
(55) |
Feb
(35) |
Mar
(56) |
Apr
(16) |
May
(20) |
Jun
(77) |
Jul
(43) |
Aug
(47) |
Sep
(29) |
Oct
(54) |
Nov
(39) |
Dec
(40) |
| 2008 |
Jan
(69) |
Feb
(79) |
Mar
(122) |
Apr
(106) |
May
(114) |
Jun
(76) |
Jul
(83) |
Aug
(71) |
Sep
(53) |
Oct
(75) |
Nov
(54) |
Dec
(43) |
| 2009 |
Jan
(32) |
Feb
(31) |
Mar
(64) |
Apr
(48) |
May
(38) |
Jun
(43) |
Jul
(35) |
Aug
(15) |
Sep
(52) |
Oct
(62) |
Nov
(62) |
Dec
(21) |
| 2010 |
Jan
(44) |
Feb
(10) |
Mar
(47) |
Apr
(22) |
May
(5) |
Jun
(54) |
Jul
(19) |
Aug
(54) |
Sep
(16) |
Oct
(15) |
Nov
(7) |
Dec
(8) |
| 2011 |
Jan
(18) |
Feb
(9) |
Mar
(5) |
Apr
(5) |
May
(41) |
Jun
(40) |
Jul
(29) |
Aug
(17) |
Sep
(12) |
Oct
(23) |
Nov
(22) |
Dec
(11) |
| 2012 |
Jan
(8) |
Feb
(24) |
Mar
(5) |
Apr
(5) |
May
(6) |
Jun
(5) |
Jul
(5) |
Aug
(5) |
Sep
(2) |
Oct
(9) |
Nov
(2) |
Dec
(18) |
| 2013 |
Jan
(25) |
Feb
(16) |
Mar
(8) |
Apr
(2) |
May
(16) |
Jun
(17) |
Jul
(2) |
Aug
(13) |
Sep
(3) |
Oct
(4) |
Nov
(1) |
Dec
|
| 2014 |
Jan
(2) |
Feb
|
Mar
(22) |
Apr
(9) |
May
(3) |
Jun
(1) |
Jul
(5) |
Aug
(11) |
Sep
(18) |
Oct
(4) |
Nov
(4) |
Dec
(3) |
| 2015 |
Jan
(2) |
Feb
|
Mar
|
Apr
(3) |
May
(4) |
Jun
(37) |
Jul
|
Aug
(4) |
Sep
(6) |
Oct
(1) |
Nov
(4) |
Dec
(2) |
| 2016 |
Jan
(9) |
Feb
(3) |
Mar
(7) |
Apr
(1) |
May
(8) |
Jun
|
Jul
|
Aug
|
Sep
(7) |
Oct
(3) |
Nov
(16) |
Dec
|
| 2017 |
Jan
(1) |
Feb
(15) |
Mar
(2) |
Apr
(12) |
May
(4) |
Jun
(7) |
Jul
(5) |
Aug
|
Sep
|
Oct
|
Nov
(23) |
Dec
(8) |
| 2018 |
Jan
(2) |
Feb
(4) |
Mar
(2) |
Apr
(8) |
May
(3) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
(5) |
Nov
(3) |
Dec
|
| 2020 |
Jan
|
Feb
(4) |
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
(12) |
Aug
(5) |
Sep
(3) |
Oct
(1) |
Nov
|
Dec
(1) |
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2025 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Shamanth <sha...@in...> - 2004-10-20 09:23:12
|
Hi
=20
I am currently using quickfix 1.8, I wanted to upgrade to 1.9.2, so I =
downloaded the source and build them in windows.=20
Both my Initiator and Acceptor are quickfix 1.9.2, I use JNI wrappers, =
and not the C++ code directly
=20
Problem:
When I send a MarketDataRequest, I get the following error in the =
Acceptor, I have pasted the original message also below.
=20
<20041020-08:37:50, FIX.4.2:ITLServer->ITLClientMD, incoming>
=
(8=3DFIX.4.2?9=3D151?35=3DV?34=3D2?49=3DITLClientMD?52=3D2004102008:37:50=
.617?56=3DITLServer?146=3D1?55=3DEUR/USD?146=3D1?55=3DEUR/USD?146=3D1?55=3D=
EUR/USD?262=3D123456?263=3D1?264=3D0?265=3D1?267=3D2?269=3D0?269=3D1?267=3D=
2?269=3D0?269=3D1?267=3D2?269=3D0?269=3D1?10=3D165?)
<20041020-08:37:50, FIX.4.2:ITLServer->ITLClientMD, event>
(Invalid message: Expected BodyLength=3D197, Recieved =
BodyLength=3D151)
=20
In my initiator log, I am printing the XML of the message before =
sending, I see that it is not getting resolved properly
<message>
<header>
<field number=3D"8"><![CDATA[FIX.4.2]]></field>
<field number=3D"35"><![CDATA[V]]></field>
<field number=3D"34"><![CDATA[2]]></field>
<field number=3D"49"><![CDATA[ITLClientMD]]></field>
<field number=3D"52"><![CDATA[20041020-08:37:50.617]]></field>
<field number=3D"56"><![CDATA[ITLServer]]></field>
</header>
<body>
<field number=3D"146"><![CDATA[1]]></field>
<field number=3D"146"><![CDATA[1]]></field>
<field number=3D"262"><![CDATA[123456]]></field>
<field number=3D"263"><![CDATA[1]]></field>
<field number=3D"264"><![CDATA[0]]></field>
<field number=3D"265"><![CDATA[1]]></field>
<field number=3D"267"><![CDATA[2]]></field>
<field number=3D"267"><![CDATA[2]]></field>
<group>
<field number=3D"55"><![CDATA[EUR/USD]]></field>
</group>
<group>
<field number=3D"269"><![CDATA[0]]></field>
</group>
<group>
<field number=3D"269"><![CDATA[1]]></field>
</group>
</body>
<trailer>
</trailer>
=20
Note: If I replace the quickfix.jar, quickfix.lib and quickfix_jni.dll =
of 1.8, then every thing works fine. I notice this problem only with =
1.9.2 jars and dlls.
=20
This is how the XML looks with 1.8 jars and dlls
=20
<message>
<header>
<field number=3D"8" value=3D"FIX.4.2"/>
<field number=3D"35" value=3D"V"/>
<field number=3D"34" value=3D"2"/>
<field number=3D"49" value=3D"ITLClientMD"/>
<field number=3D"52" value=3D"20041020-08:47:49.679"/>
<field number=3D"56" value=3D"ITLServer"/>
</header>
<body>
<field number=3D"146" value=3D"1"/>
<field number=3D"262" value=3D"123456"/>
<field number=3D"263" value=3D"1"/>
<field number=3D"264" value=3D"0"/>
<field number=3D"265" value=3D"1"/>
<field number=3D"267" value=3D"2"/>
<group>
<field number=3D"55" value=3D"EUR/USD"/>
</group>
<group>
<field number=3D"269" value=3D"0"/>
</group>
<group>
<field number=3D"269" value=3D"1"/>
</group>
</body>
<trailer>
</trailer>
</message>
=20
any idea what could be the problem, has any one else faced the same =
problem.
=20
thanks
R Shamanth
|
|
From: Caleb E. <cal...@gm...> - 2004-10-19 21:21:43
|
This isn't a huge deal, but my Application seems to be getting two onLogout callbacks when the remote end closes the connection cleanly. The first one looks like this: #0 D2FIXApp::onLogout(FIX::SessionID const&) (this=0x80f4e28, sessionId=@0x80fa9ec) at D2FIXApp.cpp:19 #1 0x405a891f in FIX::Session::disconnect() (this=0x80fa9e8) at Session.cpp:492 #2 0x405986f7 in FIX::Session::nextLogout(FIX::Message const&) (this=0x80fa9e8, logout=@0x80f4e28) at Session.cpp:270 #3 0x405c8d05 in FIX::Session::next(FIX::Message const&) (this=0x80fa9e8, message=@0x4314b910) at Session.cpp:1123 #4 0x405c6eb2 in FIX::Session::next(std::string const&) (this=0x80fa9e8, msg=@0x4314b9f0) at Session.cpp:1064 #5 0x40613a3c in FIX::ThreadedSocketConnection::processStream() (this=0x8111a70) at ThreadedSocketConnection.cpp:182 #6 0x406137e6 in FIX::ThreadedSocketConnection::readQueue() (this=0x8111a70) at ThreadedSocketConnection.cpp:144 #7 0x4061415f in FIX::ThreadedSocketConnection::queueThread(void*) (p=0x80f4e28) at ThreadedSocketConnection.cpp:219 #8 0x40a88dac in start_thread () from /lib/tls/libpthread.so.0 #9 0x40855a8a in clone () from /lib/tls/libc.so.6 and the next one comes from: #0 D2FIXApp::onLogout(FIX::SessionID const&) (this=0x80f4e28, sessionId=@0x80fa9ec) at D2FIXApp.cpp:19 #1 0x405a891f in FIX::Session::disconnect() (this=0x80fa9e8) at Session.cpp:492 #2 0x4061364f in FIX::ThreadedSocketConnection::readQueue() (this=0x8111a70) at ThreadedSocketConnection.cpp:162 #3 0x4061415f in FIX::ThreadedSocketConnection::queueThread(void*) (p=0x80f4e28) at ThreadedSocketConnection.cpp:219 #4 0x40a88dac in start_thread () from /lib/tls/libpthread.so.0 #5 0x40855a8a in clone () from /lib/tls/libc.so.6 Is this to be expected? -- Caleb Epstein cal...@gm... |
|
From: James C. D. <jc...@co...> - 2004-10-19 18:36:15
|
Vladimir, I concur with Oren. Great job and thanks for releasing this back to QuickFIX. Also, your explanation of the problem is a nice reminder for anyone mixing managed and unmanaged code. Thanks again, Jim James C. Downs Connamara Systems, LLC 53 W. Jackson Blvd Suite 1627 Chicago, IL 60604 312 - 282 - 7746 www.connamara.com -----Original Message----- From: qui...@li... [mailto:qui...@li...] On Behalf Of Vladimir Arnost Sent: Tuesday, October 19, 2004 12:03 PM To: qui...@li... Cc: Vladimir Sebesta Subject: [Quickfix-developers] Fixed spurious System.NullReferenceException in .NET Application.toApp() 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) (The exception was thrown at random code locations, but always "below" FIX.FieldMap.operator=) As I have found, the problem lies in mixing unmanaged code and garbage-collected data structures. Method toApp() creates managed wrapper class QuickFix::Message for unmanaged class FIX::Message, calls managed method toApp() and copies the (modified?) message back to FIX::Message. The problem is in the last operation, which will fail if the .NET garbage collector decides to move QuickFix::Message in memory while the unmanaged assignment operator is obliviously copying toMessage->unmanaged() back to message. This happens quite rarely (once in 10000 messages or so), but the message is lost and never sent to the client (sequence gap does not occur), which makes the problem very severe. void toApp( FIX::Message& message, const FIX::SessionID& sessionID ) [simplified] { QuickFix::Message * toMessage = create( message ); m_application->toApp( toMessage, new QuickFix::SessionID( sessionID ) ); message = toMessage->unmanaged(); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ } The solution is quite easy: (well, once you identify the problem... ;) Simply 'tag' all pointers to GC'ed classes with "__pin" keyword: QuickFix::Message __pin * toMessage = create( message ); The toMessage object stays locked in memory in the method body even if GC is activated. I have seen the problem only in toApp(), but I believe that toAdmin() is affected in the same way. Since 'pinning' a pointer for a short time does not hurt performance, I decided to 'pin' all QuickFix::Message pointers in the Application class. It is quite possible that other C#-to-C++ wrappers suffer from the same problem, but I have not analyzed them. Important note: I was unable to reproduce the problem while executing a QuickFIX application in Visual Studio.NET's debugger. The application must be executed stand-alone from the command line, because VS.NET changes the way the garbage collector works. Both Debug and Release builds produce the same erroneous behaviour. Here is the diff: --- Application.h 2004-05-31 15:27:42.000000000 +0200 +++ Application.h.new 2004-10-19 17:22:15.011923000 +0200 @@ -71,7 +71,7 @@ void toAdmin( FIX::Message& message, const FIX::SessionID& sessionID ) { - QuickFix::Message * toMessage = create( message ); + QuickFix::Message __pin * toMessage = create( message ); m_application->toAdmin( toMessage, new QuickFix::SessionID( sessionID ) ); message = toMessage->unmanaged(); } @@ -79,7 +79,7 @@ void toApp( FIX::Message& message, const FIX::SessionID& sessionID ) throw( FIX::DoNotSend& ) { - QuickFix::Message * toMessage = create( message ); + QuickFix::Message __pin * toMessage = create( message ); try { m_application->toApp( toMessage, new QuickFix::SessionID( sessionID ) ); @@ -95,7 +95,7 @@ FIX::IncorrectTagValue&, FIX::RejectLogon& ) { - QuickFix::Message * toMessage = create( message ); + QuickFix::Message __pin * toMessage = create( message ); try { m_application->fromAdmin @@ -122,7 +122,7 @@ FIX::IncorrectTagValue&, FIX::UnsupportedMessageType& ) { - QuickFix::Message * toMessage = create( message ); + QuickFix::Message __pin * toMessage = create( message ); try { m_application->fromApp @@ -153,7 +153,7 @@ FIX::MsgType msgType; unmanaged.getHeader().getField( beginString ); unmanaged.getHeader().getField( msgType ); - QuickFix::Message* message + QuickFix::Message __pin * message = m_factory->create ( beginString.getValue().c_str(), msgType.getValue().c_str() ); message->setUnmanaged( unmanaged ); Please put this patch to the official source tree ASAP. Cheers, Vlad ------------------------------------------------------------- Ing. Vladimir Arnost, Developer, FFastFill Europe Ltd. Vaclavske namesti 55, Prague, Czech Republic ________________________________________________________________________ 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 sec...@ff... This email has been scanned for all viruses by the FFastFill Email Security System. ________________________________________________________________________ ------------------------------------------------------- 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 |
|
From: Caleb E. <cal...@gm...> - 2004-10-19 17:32:16
|
On a slightly related note. I've noticed that QuickFIX can be a little over-aggressive in terms of issuing ResendRequest messages and I think it might make sense to implement some level of throttling on these. For example, if a counterparty has a large-ish number of messages in flight when a gap is detected, each will cause QF to issue a ResendRequest for the same range of missed messages. The remote side will honor all of these, resulting in several times the necessary message traffic to fill the gap. It might make sense to keep track of the range and time of the most recent ResendRequest in the SessionState and not send a new ResendRequest if the outstanding one would satisfy the same range of messages and no more than <X> seconds has elapsed. -- Caleb Epstein cal...@gm... |
|
From: Oren M. <or...@qu...> - 2004-10-19 17:22:33
|
Fantastic! We have a bug report open on this already and have had people report non-repeatable exceptions like this that happen very infrequently. When Reuters was doing their testing they reported similar problems under heavy load (which is why they ended up choosing to use the C++ API). This was our biggest open issue. Thanks! We'll add this to CVS immediately. --oren On Oct 19, 2004, at 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) > > (The exception was thrown at random code locations, but always "below" > FIX.FieldMap.operator=) > > As I have found, the problem lies in mixing unmanaged code and > garbage-collected data structures. Method toApp() creates managed > wrapper class QuickFix::Message for unmanaged class FIX::Message, calls > managed method toApp() and copies the (modified?) message back to > FIX::Message. The problem is in the last operation, which will fail if > the .NET garbage collector decides to move QuickFix::Message in memory > while the unmanaged assignment operator is obliviously copying > toMessage->unmanaged() back to message. This happens quite rarely (once > in 10000 messages or so), but the message is lost and never sent to the > client (sequence gap does not occur), which makes the problem very > severe. > > void toApp( FIX::Message& message, const FIX::SessionID& sessionID ) > [simplified] > { > QuickFix::Message * toMessage = create( message ); > m_application->toApp( toMessage, new QuickFix::SessionID( sessionID > ) ); > message = toMessage->unmanaged(); > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > } > > The solution is quite easy: (well, once you identify the problem... ;) > Simply 'tag' all pointers to GC'ed classes with "__pin" keyword: > > QuickFix::Message __pin * toMessage = create( message ); > > The toMessage object stays locked in memory in the method body even if > GC is activated. > I have seen the problem only in toApp(), but I believe that toAdmin() > is > affected in the same way. Since 'pinning' a pointer for a short time > does not hurt performance, I decided to 'pin' all QuickFix::Message > pointers in the Application class. > > It is quite possible that other C#-to-C++ wrappers suffer from the same > problem, but I have not analyzed them. > > Important note: I was unable to reproduce the problem while executing a > QuickFIX application in Visual Studio.NET's debugger. The application > must be executed stand-alone from the command line, because VS.NET > changes the way the garbage collector works. Both Debug and Release > builds produce the same erroneous behaviour. > > > Here is the diff: > > --- Application.h 2004-05-31 15:27:42.000000000 +0200 > +++ Application.h.new 2004-10-19 17:22:15.011923000 +0200 > @@ -71,7 +71,7 @@ > > void toAdmin( FIX::Message& message, const FIX::SessionID& sessionID > ) > { > - QuickFix::Message * toMessage = create( message ); > + QuickFix::Message __pin * toMessage = create( message ); > m_application->toAdmin( toMessage, new QuickFix::SessionID( > sessionID ) ); > message = toMessage->unmanaged(); > } > @@ -79,7 +79,7 @@ > void toApp( FIX::Message& message, const FIX::SessionID& sessionID ) > throw( FIX::DoNotSend& ) > { > - QuickFix::Message * toMessage = create( message ); > + QuickFix::Message __pin * toMessage = create( message ); > try > { > m_application->toApp( toMessage, new QuickFix::SessionID( > sessionID ) ); > @@ -95,7 +95,7 @@ > FIX::IncorrectTagValue&, > FIX::RejectLogon& ) > { > - QuickFix::Message * toMessage = create( message ); > + QuickFix::Message __pin * toMessage = create( message ); > try > { > m_application->fromAdmin > @@ -122,7 +122,7 @@ > FIX::IncorrectTagValue&, > FIX::UnsupportedMessageType& ) > { > - QuickFix::Message * toMessage = create( message ); > + QuickFix::Message __pin * toMessage = create( message ); > try > { > m_application->fromApp > @@ -153,7 +153,7 @@ > FIX::MsgType msgType; > unmanaged.getHeader().getField( beginString ); > unmanaged.getHeader().getField( msgType ); > - QuickFix::Message* message > + QuickFix::Message __pin * message > = m_factory->create > ( beginString.getValue().c_str(), msgType.getValue().c_str() ); > message->setUnmanaged( unmanaged ); > > > Please put this patch to the official source tree ASAP. > > Cheers, > Vlad > > ------------------------------------------------------------- > Ing. Vladimir Arnost, Developer, FFastFill Europe Ltd. > Vaclavske namesti 55, Prague, Czech Republic > > _______________________________________________________________________ > _ > 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 > sec...@ff... > > This email has been scanned for all viruses by the FFastFill Email > Security System. > _______________________________________________________________________ > _ > > > ------------------------------------------------------- > 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 > |
|
From: Vladimir A. <Vla...@FF...> - 2004-10-19 17:03:13
|
Oren,
I=20have=20fixed=20a=20nasty=20bug=20in=20.NET=20Application=20class=20in=20=
QuickFIX=201.9.2.
From=20time=20to=20time,=20especially=20under=20high=20system=20load,=20se=
nding=20a=20FIX
message=20throws=20an=20exception=20like=20this=20one:
System.NullReferenceException:=20Object=20reference=20not=20set=20to=20an=20=
instance
of=20an=20object.
=20=20=20at=20FIX.message_order.=3D(message_order*=20,=20message_order*=20=
)
=20=20=20at=20FIX.message_order.__ctor(message_order*=20,=20message_order*=
=20copy)
=20=20=20at
std._Tree<std::_Tmap_traits<int,FIX::FieldBase,FIX::message_order,...>
>.key_comp(_Tree<...>*=20,=20message_order*=20)
=20=20=20at=20FIX.FieldMap.=3D(FieldMap*=20,=20FieldMap*=20)
=20=20=20at=20FIX.Message.=3D(Message*=20,=20Message*=20)
=20=20=20at=20Application.toApp(Application*=20,=20Message*=20message,=20S=
essionID*
sessionID)
=20=20=20at=20FIX.Session.sendToTarget(Message*=20,=20SessionID*=20)
=20=20=20at=20QuickFix.Session.sendToTarget(Message=20message,=20SessionID=
sessionID)
(The=20exception=20was=20thrown=20at=20random=20code=20locations,=20but=20=
always=20"below"
FIX.FieldMap.operator=3D)
As=20I=20have=20found,=20the=20problem=20lies=20in=20mixing=20unmanaged=20=
code=20and
garbage-collected=20data=20structures.=20Method=20toApp()=20creates=20mana=
ged
wrapper=20class=20QuickFix::Message=20for=20unmanaged=20class=20FIX::Messa=
ge,=20calls
managed=20method=20toApp()=20and=20copies=20the=20(modified?)=20message=20=
back=20to
FIX::Message.=20The=20problem=20is=20in=20the=20last=20operation,=20which=20=
will=20fail=20if
the=20.NET=20garbage=20collector=20decides=20to=20move=20QuickFix::Message=
=20in=20memory
while=20the=20unmanaged=20assignment=20operator=20is=20obliviously=20copyi=
ng
toMessage->unmanaged()=20back=20to=20message.=20This=20happens=20quite=20r=
arely=20(once
in=2010000=20messages=20or=20so),=20but=20the=20message=20is=20lost=20and=20=
never=20sent=20to=20the
client=20(sequence=20gap=20does=20not=20occur),=20which=20makes=20the=20pr=
oblem=20very
severe.
=20=20void=20toApp(=20FIX::Message&=20message,=20const=20FIX::SessionID&=20=
sessionID=20)
[simplified]
=20=20{
=20=20=20=20QuickFix::Message=20*=20toMessage=20=3D=20create(=20message=20=
);
=20=20=20=20m_application->toApp(=20toMessage,=20new=20QuickFix::SessionID=
(=20sessionID
)=20);
=20=20=20=20message=20=3D=20toMessage->unmanaged();
=20=20=20=20^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
=20=20}
The=20solution=20is=20quite=20easy:=20(well,=20once=20you=20identify=20the=
=20problem...=20;)
Simply=20'tag'=20all=20pointers=20to=20GC'ed=20classes=20with=20"__pin"=20=
keyword:
=20=20=20=20QuickFix::Message=20__pin=20*=20toMessage=20=3D=20create(=20me=
ssage=20);
The=20toMessage=20object=20stays=20locked=20in=20memory=20in=20the=20metho=
d=20body=20even=20if
GC=20is=20activated.
I=20have=20seen=20the=20problem=20only=20in=20toApp(),=20but=20I=20believe=
=20that=20toAdmin()=20is
affected=20in=20the=20same=20way.=20Since=20'pinning'=20a=20pointer=20for=20=
a=20short=20time
does=20not=20hurt=20performance,=20I=20decided=20to=20'pin'=20all=20QuickF=
ix::Message
pointers=20in=20the=20Application=20class.
It=20is=20quite=20possible=20that=20other=20C#-to-C++=20wrappers=20suffer=20=
from=20the=20same
problem,=20but=20I=20have=20not=20analyzed=20them.
Important=20note:=20I=20was=20unable=20to=20reproduce=20the=20problem=20wh=
ile=20executing=20a
QuickFIX=20application=20in=20Visual=20Studio.NET's=20debugger.=20The=20ap=
plication
must=20be=20executed=20stand-alone=20from=20the=20command=20line,=20becaus=
e=20VS.NET
changes=20the=20way=20the=20garbage=20collector=20works.=20Both=20Debug=20=
and=20Release
builds=20produce=20the=20same=20erroneous=20behaviour.
Here=20is=20the=20diff:
---=20Application.h=092004-05-31=2015:27:42.000000000=20+0200
+++=20Application.h.new=092004-10-19=2017:22:15.011923000=20+0200
@@=20-71,7=20+71,7=20@@
=20
=20=20=20void=20toAdmin(=20FIX::Message&=20message,=20const=20FIX::Session=
ID&=20sessionID
)
=20=20=20{
-=20=20=20=20QuickFix::Message=20*=20toMessage=20=3D=20create(=20message=20=
);
+=20=20=20=20QuickFix::Message=20__pin=20*=20toMessage=20=3D=20create(=20m=
essage=20);
=20=20=20=20=20m_application->toAdmin(=20toMessage,=20new=20QuickFix::Sess=
ionID(
sessionID=20)=20);
=20=20=20=20=20message=20=3D=20toMessage->unmanaged();
=20=20=20}
@@=20-79,7=20+79,7=20@@
=20=20=20void=20toApp(=20FIX::Message&=20message,=20const=20FIX::SessionID=
&=20sessionID=20)
=20=20=20throw(=20FIX::DoNotSend&=20)
=20=20=20{
-=20=20=20=20QuickFix::Message=20*=20toMessage=20=3D=20create(=20message=20=
);
+=20=20=20=20QuickFix::Message=20__pin=20*=20toMessage=20=3D=20create(=20m=
essage=20);
=20=20=20=20=20try
=20=20=20=20=20{
=20=20=20=20=20=20=20m_application->toApp(=20toMessage,=20new=20QuickFix::=
SessionID(
sessionID=20)=20);
@@=20-95,7=20+95,7=20@@
=20=09=20FIX::IncorrectTagValue&,=20
=20=09=20FIX::RejectLogon&=20)
=20=20=20{
-=20=20=20=20QuickFix::Message=20*=20toMessage=20=3D=20create(=20message=20=
);
+=20=20=20=20QuickFix::Message=20__pin=20*=20toMessage=20=3D=20create(=20m=
essage=20);
=20=20=20=20=20try
=20=20=20=20=20{
=20=20=20=20=20=20=20m_application->fromAdmin
@@=20-122,7=20+122,7=20@@
=20=09=20FIX::IncorrectTagValue&,=20
=20=09=20FIX::UnsupportedMessageType&=20)
=20=20=20{
-=20=20=20=20QuickFix::Message=20*=20toMessage=20=3D=20create(=20message=20=
);
+=20=20=20=20QuickFix::Message=20__pin=20*=20toMessage=20=3D=20create(=20m=
essage=20);
=20=20=20=20=20try
=20=20=20=20=20{
=20=20=20=20=20=20=20m_application->fromApp
@@=20-153,7=20+153,7=20@@
=20=20=20=20=20FIX::MsgType=20msgType;
=20=20=20=20=20unmanaged.getHeader().getField(=20beginString=20);
=20=20=20=20=20unmanaged.getHeader().getField(=20msgType=20);
-=20=20=20=20QuickFix::Message*=20message=20
+=20=20=20=20QuickFix::Message=20__pin=20*=20message=20
=20=20=20=20=20=20=20=3D=20m_factory->create
=20=20=20=20=20=20=20(=20beginString.getValue().c_str(),=20msgType.getValu=
e().c_str()=20);
=20=20=20=20=20message->setUnmanaged(=20unmanaged=20);
Please=20put=20this=20patch=20to=20the=20official=20source=20tree=20ASAP.
Cheers,
=20=20Vlad
-------------------------------------------------------------
Ing.=20Vladimir=20Arnost,=20Developer,=20FFastFill=20Europe=20Ltd.
Vaclavske=20namesti=2055,=20Prague,=20Czech=20Republic
________________________________________________________________________
This=20email=20and=20any=20files=20transmitted=20with=20it=20are=20confide=
ntial=20and
intended=20solely=20for=20the=20use=20of=20the=20individual=20or=20entity=20=
to=20whom=20they
are=20addressed.=20If=20you=20have=20received=20this=20email=20in=20error=20=
please=20notify
sec...@ff...
This=20email=20has=20been=20scanned=20for=20all=20viruses=20by=20the=20FFa=
stFill=20Email
Security=20System.
________________________________________________________________________
|
|
From: Oren M. <or...@qu...> - 2004-10-19 15:06:11
|
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=20
> receive an ack, does not necessarily mean the counter-party did not=20
> receive the logon. If the sequence number was not incremented, and=20
> they had actually received it without acknowledging, you would then=20
> encounter disconnect scenarios due to too low sequence numbers at some=20=
> point. A much worse position to be in as it cannot be resolved=20
> 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=20
> this case we are talking about logon messages, all that is required is=20=
> a 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 =93acceptor=94 send =
a=20
>> resendRequest to the =93initiator=94
>>
>> 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 =932147483647=94 the maximum value in resend request as =
per=20
>> fix protocol or should =930=94(infinity) be considered as the max =
valueis=20
>> considered as the maximum number?
>>
>> thanks
>>
>> R Shamanth
|
|
From: Oren M. <or...@qu...> - 2004-10-19 14:59:37
|
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 the=20=
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 since=20=
the two engines can resolve this on their own. And since in this case=20=
we are talking about logon messages, all that is required is a single=20
gap fill message to put everything in order.
Answer2:
Depends on the version. For FIX.4.2 and higher, the value should be 0.=20=
For versions 4.1 and earlier, a special value of 999999 is used. I'm=20=
a bit curious as to what is going on here. Is both the initiator and=20
acceptor QuickFIX. It seems strange because since QuickFIX 1.6, the=20
EndSeqNo is always send either 0 or 999999, never another value. Based=20=
on this I'm guessing the acceptor in this scenario is not QuickFIX, is=20=
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 such=20=
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 =93acceptor=94 send =
a=20
> resendRequest to the =93initiator=94
>
> 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 =932147483647=94 the maximum value in resend request as =
per=20
> fix protocol or should =930=94(infinity) be considered as the max =
valueis=20
> considered as the maximum number?
>
> thanks
> R Shamanth
|
|
From: Shamanth <sha...@in...> - 2004-10-19 12:08:03
|
Hi I am using quickfix 1.8, While testing due to some network problems we got disconnected from the = "Acceptor". In the mean time, our "initiator" tried reconnecting to the = "acceptor" every 30secs.=20 It tried it 8 times before it could get an ack for its logon message.=20 Problem1: Our initiator, sent 8 logon messages and only the 9th logon = message was ack by the acceptor. But in the meantime, our initiator = incremented its MsgSeqNo, so when both the initiator and acceptor got = connected, there was a mismatch of SeqNo, and the "acceptor" send a = resendRequest to the "initiator" Question: Is there a way we can prevent the quickfix initiator from = 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 = SeqNo of the messages received was correct. Problem2: After connecting again the Acceptor sent, a resend request = FROM: 0 TO: 2147483647, our initiator had not sent so many messages, so = it considers it as an error condition and stops responding to the = acceptor. Is "2147483647" the maximum value in resend request as per fix = protocol or should "0"(infinity) be considered as the max valueis = considered as the maximum number? thanks R Shamanth |
|
From: Brendan B. B. <br...@ka...> - 2004-10-18 21:38:34
|
Hi, I think that in process_sleep( double s ) #ifdef _MSC_VER Sleep( (long) s * 1000 ); #else ... #endif should instead be: Sleep( (long) (s * 1000.0) ); as VC++ 6.0 appears to compile the former as long * 1000 which for say s = 0.5 results in 0 instead of 500. Regards, Brendan |
|
From: James W. <wi...@wi...> - 2004-10-16 13:05:44
|
Folks, When compiling QuickFIX 1.8.0 and when compiling my applications that use it, I'm repeatedly encountering internal compiler errors. I frequently see messages like: free(): invalid pointer 0x8dcb250! free(): invalid pointer 0x8dc9610! during the compiles, and often such as the following, from my own application: ----- begin text ----- /opt/MarketCASTDev/support/include/quickfix/SessionSettings.h: In function ` void __static_initialization_and_destruction_0(int, int)': /opt/MarketCASTDev/support/include/quickfix/SessionSettings.h:62: internal compiler error: in verify_local_live_at_start, at flow.c:601 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. For Debian GNU/Linux specific bug reporting instructions, see <URL:file:///usr/share/doc/gcc-3.3/README.Bugs>. ----- end text ----- Here is an example from an attempted compile of QF 1.9.2: ----- begin text ----- g++ -DHAVE_CONFIG_H -I. -I. -I../../.. -I.. -g -O2 -I/usr/include/stlport -I/opt/RAIDD/db/mysql/include/mysql -I/usr/include/libxml2 -I/include -I/include/linux -O0 -g -MT MessagesTestCase.lo -MD -MP -MF .deps/MessagesTestCase.Tpo -c MessagesTestCase.cpp -fPIC -DPIC -o .libs/MessagesTestCase.o In file included from ../Message.h:33, from MessagesTestCase.h:26, from MessagesTestCase.cpp:27: /usr/include/stlport/stl/_tree.h: In member function `typename _Traits::reference _STL::_Rb_tree_iterator<_Value, _Traits>::operator*() const [with _Value = _STL::pair<const _STL::string, _STL::set<int, _STL::less<int>, _STL::allocator<int> > >, _Traits = _STL::_Const_traits<_STL::pair<const _STL::string, _STL::set<int, _STL::less<int>, _STL::allocator<int> > > >]': Internal compiler error: Error reporting routines re-entered. Please submit a full bug report, with preprocessed source if appropriate. For Debian GNU/Linux specific bug reporting instructions, see <URL:http://gcc.gnu.org/bugs.html>. ----- end text ----- Has anyone else seen this behavior? I'm running Debian testing (i.e. Sarge) fully up to date; g++ is at pkg version 3.3.4-13. The errors seem to be very random. Sometimes, if I execute make several times, everything will eventually compile to a working application, but who knows if it's *really* a working application? I mainly see this in my own applications, but have also seen it, more sporadically, when compiling QuickFIX itself. Perhaps the fact that I'm linking in and making use of some C libraries, specifically xml2 v 2.6.11 and glib v 2.4.4, that is making the problem worse, but I don't see any reason why I shouldn't be able to use these libs in a C++ app. I'm trying to figure out if I've got a corrupted install of the compiler that's causing this, or maybe bad RAM, or something else. If my experience isn't unique, I'd feel a little better (I think)... thanks, Jim |
|
From: Aaron v. M. <aa...@ex...> - 2004-10-15 19:05:31
|
Hi everyone, I am working on a financial services system in PHP, and I am interested in using the quickfix engine to process transactions. Ideally I'd like to use PHP for this, since the rest of the codebase is already PHP. I see that the python bindings for quickfix were made using swig. I attempted to use the same swig file (src/python/quickfix.i) to create PHP bindings in a src/php directory, but I ended up with only warnings and parse errors from gcc when compiling. Has anyone had any experience creating bindings in new languages for quickfick? Cheers, -Aaron van Meerten |
|
From: Jon D. <jd...@wi...> - 2004-10-15 16:26:59
|
I'm having problems retrieving the milliseconds portion of a TransactTime field in Java. Example: ...... TransactTime transTime = new TransactTime(); message.getField(transTime); ...... calling transTime.getValue() returns a Date without milliseconds. Could I be calling this incorrectly or possibliy missed something when building QF and the JNI library? This is on Windows. I'm not able to test this on our RH boxes. QF 1.9.0 VS .Net 2002 (7.0.9466) Java SDK 1.4.2_04 Windows XP Pro -jd- |
|
From: Andrew S. <ab...@gm...> - 2004-10-13 20:55:52
|
Do you have SocketReuseAddress=Y in your config? On Wed, 13 Oct 2004 12:48:26 -0500 (CDT), Jon Dahl <jd...@wi...> 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 > > Sorry, QF 1.9.0 not 1.9.2 > > > 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 > > > > I've noticed a problem we're having when our acceptor app is shutdown > > while clients are connected. It seems as if the sockets are kept in a > > CLOSE_WAIT state after shutdown when running netstat filtering for our > > listening port. > > > > The reason why I ask this is because we can't restart the acceptor until > > the OS clears out the sockets in the CLOSE_WAIT state. > > > > Could this be a case of not properly shutting down the server? Up unitl > > now, I thought I was shutting down correctly but now I'm wondering. > > > > > > SocketAcceptor > > QF 1.9.2 > > RHAS 2.1 > > g++ 3.0.4 > > > > > > -jd- > > > > > > > > > > > > ------------------------------------------------------- > > 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 > > -- > > ------------------------------------------------------- > 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 > |
|
From: Jon D. <jd...@wi...> - 2004-10-13 18:57:19
|
>Have you tried setting SocketReuseAddress=Y No I have not, but interestingly enough, it did this with an earlier version of the QF library pre 1.9.0. With 1.9.0 it doesn't do it anymore. I'll add this to the config file to be safe. -jd- > Have you tried setting SocketReuseAddress=Y? > > On Oct 13, 2004, at 12:33 PM, 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 >> >> I've noticed a problem we're having when our acceptor app is shutdown >> while clients are connected. It seems as if the sockets are kept in a >> CLOSE_WAIT state after shutdown when running netstat filtering for our >> listening port. >> >> The reason why I ask this is because we can't restart the acceptor >> until >> the OS clears out the sockets in the CLOSE_WAIT state. >> >> Could this be a case of not properly shutting down the server? Up >> unitl now, I thought I was shutting down correctly but now I'm >> wondering. >> >> >> SocketAcceptor >> QF 1.9.2 >> RHAS 2.1 >> g++ 3.0.4 >> >> >> -jd- >> >> >> >> >> >> ------------------------------------------------------- >> 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 -- |
|
From: Caleb E. <cal...@gm...> - 2004-10-13 18:44:32
|
Have you set SocketReuseAddress=Y in your config file? -- Caleb Epstein cal...@gm... |
|
From: Jon D. <jd...@wi...> - 2004-10-13 18:03:49
|
gah! ... silly me copied over an older lib ... please disregard. -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 > > Sorry, QF 1.9.0 not 1.9.2 > >> 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 >> >> I've noticed a problem we're having when our acceptor app is shutdown >> while clients are connected. It seems as if the sockets are kept in a >> CLOSE_WAIT state after shutdown when running netstat filtering for our >> listening port. >> >> The reason why I ask this is because we can't restart the acceptor >> until the OS clears out the sockets in the CLOSE_WAIT state. >> >> Could this be a case of not properly shutting down the server? Up >> unitl now, I thought I was shutting down correctly but now I'm >> wondering. >> >> >> SocketAcceptor >> QF 1.9.2 >> RHAS 2.1 >> g++ 3.0.4 >> >> >> -jd- >> >> >> >> >> >> ------------------------------------------------------- >> 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 > > > -- > > > > > > ------------------------------------------------------- > 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 -- |
|
From: Oren M. <or...@qu...> - 2004-10-13 18:03:23
|
Have you tried setting SocketReuseAddress=Y? On Oct 13, 2004, at 12:33 PM, 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 > > I've noticed a problem we're having when our acceptor app is shutdown > while clients are connected. It seems as if the sockets are kept in a > CLOSE_WAIT state after shutdown when running netstat filtering for our > listening port. > > The reason why I ask this is because we can't restart the acceptor > until > the OS clears out the sockets in the CLOSE_WAIT state. > > Could this be a case of not properly shutting down the server? Up unitl > now, I thought I was shutting down correctly but now I'm wondering. > > > SocketAcceptor > QF 1.9.2 > RHAS 2.1 > g++ 3.0.4 > > > -jd- > > > > > > ------------------------------------------------------- > 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 > |
|
From: Emil V. <que...@ho...> - 2004-10-13 17:57:11
|
Thanks, Oren, Well, deriving from the logger can possibly help, but the true reason comes with the incoming message, so I guess I would have to extract if from the string message, it'll be kind of double work :) Best regards, Emil >From: Oren Miller <or...@qu...> >To: "Emil Vladov" <que...@ho...> >CC: qui...@li... >Subject: Re: [Quickfix-developers] Finding the Logout reason >Date: Wed, 13 Oct 2004 09:13:57 -0500 >MIME-Version: 1.0 (Apple Message framework v619) >Received: from sc8-sf-list1.sourceforge.net ([66.35.250.206]) by >mc1-f28.hotmail.com with Microsoft SMTPSVC(5.0.2195.6824); Wed, 13 Oct 2004 >07:26:39 -0700 >Received: from localhost ([127.0.0.1] helo=projects.sourceforge.net)by >sc8-sf-list1.sourceforge.net with esmtp (Exim 4.30)id 1CHk25-0008Lv-86; >Wed, 13 Oct 2004 07:23:13 -0700 >Received: from sc8-sf-mx2-b.sourceforge.net ([10.3.1.12] >helo=sc8-sf-mx2.sourceforge.net)by sc8-sf-list1.sourceforge.net with esmtp >(Exim 4.30)id 1CHk15-00089I-FNfor >qui...@li...; Wed, 13 Oct 2004 07:22:11 -0700 >Received: from smtpout01-04.mesa1.secureserver.net ([64.202.165.79])by >sc8-sf-mx2.sourceforge.net with smtp (Exim 4.41)id 1CHjzg-0006Ep-BBfor >qui...@li...; Wed, 13 Oct 2004 07:22:11 -0700 >Received: (qmail 19493 invoked from network); 13 Oct 2004 14:13:59 -0000 >Received: from unknown (160.79.18.60) by >smtpout01-04.mesa1.secureserver.net (64.202.165.79) with ESMTP; 13 Oct 2004 >14:13:59 -0000 >X-Message-Info: QIy1oIULmHdrbBPmRzJzdD+ffmhII2Z8 >In-Reply-To: <BAY...@ho...> >References: <BAY...@ho...> >Message-Id: <1F4...@qu...> >X-Mailer: Apple Mail (2.619) >X-Spam-Score: 0.1 (/) >X-Spam-Report: Spam Filtering performed by sourceforge.net.See >http://spamassassin.org/tag/ for more details.Report problems to >http://sf.net/tracker/?func=add&group_id=1&atid=2000010.0 >SF_CHICKENPOX_SLASH BODY: Text interparsed with /0.0 SF_CHICKENPOX_MINUS > BODY: Text interparsed with -0.0 SF_CHICKENPOX_AT BODY: Text >interparsed with @0.0 SF_CHICKENPOX_APOSTROPHE BODY: Text interparsed with >'0.0 SF_CHICKENPOX_PERIOD BODY: Text interparsed with .0.0 >SF_CHICKENPOX_QUESTION BODY: Text interparsed with ? >Errors-To: qui...@li... >X-BeenThere: qui...@li... >X-Mailman-Version: 2.0.9-sf.net >Precedence: bulk >List-Unsubscribe: ><https://lists.sourceforge.net/lists/listinfo/quickfix-developers>,<mailto:qui...@li...?subject=unsubscribe> >List-Id: <quickfix-developers.lists.sourceforge.net> >List-Post: <mailto:qui...@li...> >List-Help: ><mailto:qui...@li...?subject=help> >List-Subscribe: ><https://lists.sourceforge.net/lists/listinfo/quickfix-developers>,<mailto:qui...@li...?subject=subscribe> >List-Archive: ><http://sourceforge.net/mailarchive/forum.php?forum=quickfix-developers> >X-Original-Date: Wed, 13 Oct 2004 09:13:57 -0500 >Return-Path: qui...@li... >X-OriginalArrivalTime: 13 Oct 2004 14:26:39.0132 (UTC) >FILETIME=[A6FC5DC0:01C4B130] > >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 > >Have you tried using the messages that come from the onEvent callback to >the logger? You can derive a class from the logger interface and have >those messages displayed to the front end. > >--oren > >On Oct 13, 2004, at 3:36 AM, Emil Vladov 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 guys, >> >>I'm having little problem here - basically I want to create a meaningful >>error message when one of the two parties disconnects abnormaly (mostly >>because of mismatched sequence numbers). >> >>Basically I want to show the "MsgSeqNum too low, expecting ..." type >>messages to the frontend. >> >>I tried taking the Text field of the Logout message in App::fromAdmin and >>App::toAdmin. When I am disconnecting the other party, it's OK. >>But when they logout me - it ain't. I traced it to Session::verify, the >>logon state is not valid, so it throws an exception and does not reach the >>fromCallback call. >> >>So I'm wondering is there some 'normal' way to get to those messages? >> >>Thanks, >>Emil >> >>_________________________________________________________________ >>Don't just search. Find. Check out the new MSN Search! >>http://search.msn.com/ >> >> >> >>------------------------------------------------------- >>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 >> > > > >------------------------------------------------------- >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 _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.com/ |
|
From: Jon D. <jd...@wi...> - 2004-10-13 17:55:35
|
Sorry, QF 1.9.0 not 1.9.2 > 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 > > I've noticed a problem we're having when our acceptor app is shutdown > while clients are connected. It seems as if the sockets are kept in a > CLOSE_WAIT state after shutdown when running netstat filtering for our > listening port. > > The reason why I ask this is because we can't restart the acceptor until > the OS clears out the sockets in the CLOSE_WAIT state. > > Could this be a case of not properly shutting down the server? Up unitl > now, I thought I was shutting down correctly but now I'm wondering. > > > SocketAcceptor > QF 1.9.2 > RHAS 2.1 > g++ 3.0.4 > > > -jd- > > > > > > ------------------------------------------------------- > 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 -- |
|
From: Jon D. <jd...@wi...> - 2004-10-13 17:40:39
|
I've noticed a problem we're having when our acceptor app is shutdown while clients are connected. It seems as if the sockets are kept in a CLOSE_WAIT state after shutdown when running netstat filtering for our listening port. The reason why I ask this is because we can't restart the acceptor until the OS clears out the sockets in the CLOSE_WAIT state. Could this be a case of not properly shutting down the server? Up unitl now, I thought I was shutting down correctly but now I'm wondering. SocketAcceptor QF 1.9.2 RHAS 2.1 g++ 3.0.4 -jd- |
|
From: Caleb E. <cal...@gm...> - 2004-10-13 16:23:52
|
This patch adds a new configuration setting called "FilenamePrototype"
which is honored by the FileLog and FileStore classes. It allows you
specify the format of the filenames created by these classes so you
can include things like datestamps and possibly omit parts of the
session ID that you don't care about.
FilenamePrototype is taken to be a string of characters with
brace-delimited tokens. The brace-delimited tokens are replaced with
the appropriate values for the session in question. By default,
FilenamePrototype is:
{BeginString}-{SenderCompID}-{TargetCompID}{-SessionQualifier}
which retains the current filename formatting standards. Tokens in
braces will be replaced by the corresponding value from the SessionID.
If the replacement value is blank (e.g. like SessionQualifier usually
is), the entire brace-delimited string is removed from the resulting
filename. This way "{-SessionQualifier}" either expands to
"-some_session_qualifier" or "".
The resulting stub filename is also run through the POSIX "strftime"
function so you can use any valid strftime escapes in your
FilenamePrototype string. You'll need to be careful so that the
filename will be the same for the duration of the session, though.
For example, if you have a week-long session, you should not use
%Y%m%d in the FilenamePrototype since this would yield different
filenames every day.
My main reason for adding this code was to add a date-stamp to the log
and store files we have to make archiving simpler and eliminate the
possibility that data can be carried over from one day to the next. I
hope others find it useful.
--
Caleb Epstein
cal...@gm...
|
|
From: Oren M. <or...@qu...> - 2004-10-13 16:12:43
|
QuickFIX considers the message has been handed off as soon as the fromApp method returns (which is what delegates to onMessage). It is at this point that the sequence numbers will be incremented. Once the sequence number is updated, QF will never pass this message to you again. In fact, it doesn't even retain any knowledge of the message apart from the fact that the sequence number has been processed. If your application works in such a way that you are not completely processing the message when it is passed to you, then your onMessage should at least put the message in a persistent queue to take ownership over the message. --oren On Oct 13, 2004, at 9:38 AM, Vijay Yadav 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 > > Hello all, > Upon receipt of a trade, I write the trade to a trade table. For this, > I extract fields from ExecutionReport object. I imagine this tells > quickfix that I have processed this specific execution report? Is there > anyway through which I can extract fields from the ExecutionReport > message and still signal Quickfix to reinvoke the ::onMessage with the > same execution report. > > 1. How does QuickFix know within the context of ::onMessage that this > message need not be sent again. > > 2. Is there a way to force QuickFix to resend the same message i.e. > reinvoke onMessage till I somehow explicitly signal that I've > successfully processed the message. > > I could store the message locally within my app and process it as and > when I deem necessary but I'm trying to see if I can do it the lazy > way. > > -- vijay > > > ------------------------------------------------------- > 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 > |
|
From: Oren M. <or...@qu...> - 2004-10-13 15:20:32
|
Steven, You're probably not likely to come across something like this for free.=20= Your best bet will probably be to add this functionality to the=20 tradeclient. --oren On Oct 12, 2004, at 9:07 PM, Steven Leung wrote: > Hi all, > > =A0 > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 I am developing a FIX sell side engine = using FIX 4.0 and=20 > quickfix 1.9.2. When I want to test with the trade client bundled in=20= > the quickfix engine, I find that it only has ordering functions (New,=20= > cancel ,replace), no option for testing Order Status Request, Don=92t=20= > Know Trade and Trade allocation. Would anyone suggest some free FIX=20 > client tools having these functions? > > =A0 > > Many thanks > > Steven |
|
From: Caleb E. <cal...@gm...> - 2004-10-13 15:17:32
|
On Tue, 12 Oct 2004 13:17:22 -0700 (PDT), Clark Sims <cla...@ya...> wrote: > SLK "upgraded" their hardware last night. On the new hardware my fix client > crashes everytime I send a resend request. The new SLK boxes spit out > messages too fast for me to read them all. It might be instructive to get a stack trace from the process when it crashes. I'm aware of at least one bug in older versions of quickfix (before 1.7.0) that can cause a crash when partial messages are read from the socket. This could be getting triggered by a burst oif traffic. -- Caleb Epstein cal...@gm... |
98 messages has been excluded from this view by a project administrator.
