quickfix-developers — QuickFIX developers forum

Re: [Quickfix-developers] How to add support for custom messages and custom signature to QuickFix?

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

If you want to generate all the classes, you will need to run the generation 
scripts in the 'spec' directory.

I don't believe there is a mehod for retrieving just the body fields.  In 
C++ this would be possible if you cast the Message to a FieldMap, but this 
isn't an option in java.  A getBody method would probably be a good 
compliment to getHeader and getTrailer.  What you can do however is iterate 
through all the fields and call toString on them one by one.  If you append 
each of the fields to a StringBuffer you should be able to reconstruct the 
body of the message.

Where you add the field is a function of what you know, when you know it, 
and how generally applicable it is.  In general, if you have a field that 
you want to make sure gets appended to every outgoing message, you should 
put it in the toApp method.  If you have a field that is specific to one 
type of message, it would make more sense to append it at the same place you 
construct that message.

--oren

----- Original Message ----- 
From: "Reiner Nix" <rei...@ma...>
To: <qui...@li...>
Sent: Wednesday, June 22, 2005 7:58 AM
Subject: [Quickfix-developers] How to add support for custom messages and 
custom signature to QuickFix?


> 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 need to extend QuickFix to support custom messages. As a first step a 
> new an
> additional data dictionary was created. Now QuickFix must be build again 
> to
> generate the code according the additional data dictionary.
> What is the correct way to build QuickFix to support this data dictionary?
>
>
> I also need to add a custom defined tag containing a digital signature to 
> a
> FIX message. To do this, I need to retrieve the body in FIX notation of a
> message where almost all fields are populated. After calculating the
> signature the message must be extended with the custom field containing 
> the
> signature and then the message can be sent.
>
> My questions:
> How can I retrieve the message body in FIX notation? I do not need the 
> header
> nor the trailer but only the body for the calculation.
>
> What is the best way to add the custom field?
> Using Java, I guess the methods Application.toApp or before calling
> Session.sendToTarget can be used. Is there a recommendation whether to use
> toApp or before calling sendToTarget.
>
> Cheers
> Reiner
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
> 

Re: [Quickfix-developers] ExecType

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

Alvin -

This probably isn't the correct forum for general FIX questions, but I
can answer this one.

OrdStatus (39) and ExecType (150) have generally used the same code
values, but for somewhat different reasons. OrdStatus gave you the
current status of the order, while ExecType told you how this
particular ExecutionReport affected the order.

Starting with FIX 4.4, they made Trade Correct (G) and Trade Cancel (H)
new ExecType codes (they were previously indicated by ExecTransType
codes). It never really made much sense to have Partial Fill (1) and
Filled (2) codes for ExecType - these are really order statuses - so
they created a new ExecType Trade (F) to have a nice, orthogonal set of
ExecTypes. Trade, Trade Correct and Trade Cancel are now all single
codes that are defined in order.

I believe Partial Fill and Filled are now used only as OrdStatus values
as of FIX 4.4.

- Brian Erst
Thynk Software, Inc.

--- Alvin Wang <AW...@FF...> wrote:

> Hi I have a pure FIX (44) question. Can anyone explain to me the 
> difference between ExecType 2(Fill) and ExecType F(Trade, fill or
> partial 
> fill)?
> 
> Thanks
> Alvin

[Quickfix-developers] ExecType

[Alvin W. <AW...@FF...>]

Hi I have a pure FIX (44) question. Can anyone explain to me the 
difference between ExecType 2(Fill) and ExecType F(Trade, fill or partial 
fill)?

Thanks
Alvin


                                                                                                                                                                                                                                                                                                    **********************************************************************
This e-mail message is intended solely for the use of the addressee.
The message may contain information that is privileged and confidential.  
Disclosure to anyone other than the intended recipient is
prohibited. If you are not the intended recipient, please do not
disseminate, distribute or copy this communication, by e-mail or
otherwise. Instead, please notify us immediately by return e-mail
(including the original message with your reply) and then delete
and discard all copies of the message. We have taken precautions to
minimize the risk of transmitting software viruses but nevertheless
advise you to carry out your own virus checks on any attachment to
this message.  We accept no liability for any loss or damage caused
by software viruses.
**********************************************************************

[Quickfix-developers] fedora core 3 unit test problem

[Brian <bri...@du...>]

hi,

i'm using the latest cvs.

during make check, the ut fails (i think on tests 146-149).

they all run fine when called with another socket (5002) but
not with 5000 which is in the scripts... (check.sh)

at runs fine with either...

brian

Re: [Quickfix-developers] Java question

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

Christopher Kang wrote:
> I'm coding in Java and so I tried following the java example code on
> the quickfix website, but I can't seem to compile.
> 
> In the MyClass.java example on the website, a Settings object is created:
> 
> "Settings settings = new Settings(new FileInputStream(fileName));"

Chris, the example in the QuickFIX docs is wrong -- as Steve pointed out: SessionSettings 
is the right class here.

I fixed the example in the CVS repository.

Oren, will you update the web page after the next release 1.10.0?

Cheers, Jörg

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

RE: [Quickfix-developers] Java question

[Steve B. <st...@te...>]

Hi Chris,

Did you mean to use SessionSettings rather than Settings?

Steve

> -----Original Message-----
> From: qui...@li... =
[mailto:quickfix-
> dev...@li...] On Behalf Of Christopher Kang
> Sent: Wednesday, June 22, 2005 4:44 PM
> To: qui...@li...
> Subject: [Quickfix-developers] Java question
>=20
> 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
>=20
> Thank you everyone for contributing to the open source community.  It
> proves that open source tools can work.
>=20
> I am thinking about using quickfix and want to be able to start
> writing small applications, but I've seem to run into an error.
>=20
> I'm coding in Java and so I tried following the java example code on
> the quickfix website, but I can't seem to compile.
>=20
> In the MyClass.java example on the website, a Settings object is =
created:
>=20
> "Settings settings =3D new Settings(new FileInputStream(fileName));"
>=20
> However, the compile can't find this object.  I am assuming that the
> Settings object is something that should be able to be found in the
> quickfix.jar file (like MessageStoreFactory), but when I look in the
> quickfix.jar file, I am unable to find it.
> My classpath is correct since my compile doesn't complain about any of
> the other objects.
>=20
> Am I missing something here?
>=20
> I obtained the quickfix.jar file from the quickfix-bin-vc7-1.9.4.zip
> file on the website (windows installer).
>=20
>=20
> Thank you again for being such an active community and for addressing
> this concern.
>=20
> -Chris Kang
>=20
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&op=3Dick
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers

[Quickfix-developers] Java question

[Christopher K. <chr...@gm...>]

Thank you everyone for contributing to the open source community.  It
proves that open source tools can work.

I am thinking about using quickfix and want to be able to start
writing small applications, but I've seem to run into an error.

I'm coding in Java and so I tried following the java example code on
the quickfix website, but I can't seem to compile.

In the MyClass.java example on the website, a Settings object is created:

"Settings settings =3D new Settings(new FileInputStream(fileName));"

However, the compile can't find this object.  I am assuming that the
Settings object is something that should be able to be found in the
quickfix.jar file (like MessageStoreFactory), but when I look in the
quickfix.jar file, I am unable to find it.
My classpath is correct since my compile doesn't complain about any of
the other objects.

Am I missing something here?

I obtained the quickfix.jar file from the quickfix-bin-vc7-1.9.4.zip
file on the website (windows installer).


Thank you again for being such an active community and for addressing
this concern.

-Chris Kang

[Quickfix-developers] How to add support for custom messages and custom signature to QuickFix?

[Reiner N. <rei...@ma...>]

Hi,

I need to extend QuickFix to support custom messages. As a first step a new an 
additional data dictionary was created. Now QuickFix must be build again to 
generate the code according the additional data dictionary.
What is the correct way to build QuickFix to support this data dictionary? 


I also need to add a custom defined tag containing a digital signature to a 
FIX message. To do this, I need to retrieve the body in FIX notation of a 
message where almost all fields are populated. After calculating the 
signature the message must be extended with the custom field containing the 
signature and then the message can be sent.

My questions:
How can I retrieve the message body in FIX notation? I do not need the header 
nor the trailer but only the body for the calculation.

What is the best way to add the custom field? 
Using Java, I guess the methods Application.toApp or before calling 
Session.sendToTarget can be used. Is there a recommendation whether to use 
toApp or before calling sendToTarget.

Cheers
Reiner

Re: [Quickfix-developers] crash when upgrade to 1.9.4

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

On 6/21/05, Sean Kirkpatrick <Sea...@pi...> wrote:

> I apologize for being so annoying about this, but I just now seem to
> have resolved this issue.  I wiped everything out for quickfix and
> untarred the source again (same source used originally).  I then
> ran ./configure --with-stlport=3D/usr/local --disable-callstack.  I am
> using GCC 3.2.3 here.  I then went directly to src/C++ and ran make and
> make install from there to build the libraries and install the header
> files.  I ran ldconfig -v and rebuilt my app.  Now the exceptions are
> being thrown and caught as expected.  One thing I did notice is that
> the library binaries are different sizes.  Is there any reason why
> building from src/C++ would yield different results?

Probably because you had old object files sitting around that were
built with a different compiler, or with other differences in the
compiler settings.

--=20
Caleb Epstein
caleb dot epstein at gmail dot com

RE: [Quickfix-developers] crash when upgrade to 1.9.4

[Sean K. <Sea...@Pi...>]

I apologize for being so annoying about this, but I just now seem to
have resolved this issue.  I wiped everything out for quickfix and=20
untarred the source again (same source used originally).  I then
ran ./configure --with-stlport=3D/usr/local --disable-callstack.  I am
using GCC 3.2.3 here.  I then went directly to src/C++ and ran make and=20
make install from there to build the libraries and install the header
files.  I ran ldconfig -v and rebuilt my app.  Now the exceptions are
being thrown and caught as expected.  One thing I did notice is that
the library binaries are different sizes.  Is there any reason why
building from src/C++ would yield different results?

Thanks,
Sean

> -----Original Message-----
> From: qui...@li...
> [mailto:qui...@li...]On Behalf Of
> Sean Kirkpatrick
> Sent: Tuesday, June 21, 2005 4:03 PM
> To: Caleb Epstein
> Cc: qui...@li...
> Subject: RE: [Quickfix-developers] crash when upgrade to 1.9.4
>=20
>=20
> QuickFIX Documentation:=20
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX FAQ:=20
> http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> QuickFIX Support: http://www.quickfixengine.org/services.html
>=20
> We're using GCC 3.2.3 to build the binaries.  Thanks for you=20
> time/input.
>=20
> > -----Original Message-----
> > From: Caleb Epstein [mailto:cal...@gm...]
> > Sent: Tuesday, June 21, 2005 4:00 PM
> > To: Sean Kirkpatrick
> > Cc: qui...@li...
> > Subject: Re: [Quickfix-developers] crash when upgrade to 1.9.4
> >=20
> >=20
> > On 6/21/05, Sean Kirkpatrick=20
> > <Sea...@pi...> wrote:
> >=20
> > > Additional Info:
> > >=20
> > > We are using STLport 4.6.2 and I ran:
> > >         ./configure --with-stlport=3D/usr/local =
--disable-callstack
> > > before building quickfix.  I also tried adding=20
> > --enable-shared, after some
> > > googling, but that didn't seem to make a difference...
> >=20
> >=20
> > This is starting to look like an issue for your platform vendor to
> > have to answer.  Also, which version of gcc are you using?  I'm
> > praying its not 2.95.x...  If it is, thats probably a big source of
> > your troubles.  You should switch to gcc 3.3.x or 3.4.x and drop
> > STLport.
> >=20
> > --=20
> > Caleb Epstein
> > caleb dot epstein at gmail dot com
> >=20
>=20
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&op=3Dick
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>=20

RE: [Quickfix-developers] crash when upgrade to 1.9.4

[Sean K. <Sea...@Pi...>]

We're using GCC 3.2.3 to build the binaries.  Thanks for you time/input.

> -----Original Message-----
> From: Caleb Epstein [mailto:cal...@gm...]
> Sent: Tuesday, June 21, 2005 4:00 PM
> To: Sean Kirkpatrick
> Cc: qui...@li...
> Subject: Re: [Quickfix-developers] crash when upgrade to 1.9.4
>=20
>=20
> On 6/21/05, Sean Kirkpatrick=20
> <Sea...@pi...> wrote:
>=20
> > Additional Info:
> >=20
> > We are using STLport 4.6.2 and I ran:
> >         ./configure --with-stlport=3D/usr/local --disable-callstack
> > before building quickfix.  I also tried adding=20
> --enable-shared, after some
> > googling, but that didn't seem to make a difference...
>=20
>=20
> This is starting to look like an issue for your platform vendor to
> have to answer.  Also, which version of gcc are you using?  I'm
> praying its not 2.95.x...  If it is, thats probably a big source of
> your troubles.  You should switch to gcc 3.3.x or 3.4.x and drop
> STLport.
>=20
> --=20
> Caleb Epstein
> caleb dot epstein at gmail dot com
>=20

Re: [Quickfix-developers] crash when upgrade to 1.9.4

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

On 6/21/05, Sean Kirkpatrick <Sea...@pi...> wrote:

> Additional Info:
>=20
> We are using STLport 4.6.2 and I ran:
>         ./configure --with-stlport=3D/usr/local --disable-callstack
> before building quickfix.  I also tried adding --enable-shared, after som=
e
> googling, but that didn't seem to make a difference...


This is starting to look like an issue for your platform vendor to
have to answer.  Also, which version of gcc are you using?  I'm
praying its not 2.95.x...  If it is, thats probably a big source of
your troubles.  You should switch to gcc 3.3.x or 3.4.x and drop
STLport.

--=20
Caleb Epstein
caleb dot epstein at gmail dot com

RE: [Quickfix-developers] crash when upgrade to 1.9.4

[Sean K. <Sea...@Pi...>]

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

See below.

> -----Original Message-----
> From: Caleb Epstein [mailto:cal...@gm...]
> Sent: Thursday, June 16, 2005 6:02 PM
> To: Sean Kirkpatrick
> Cc: qui...@li...
> Subject: Re: [Quickfix-developers] crash when upgrade to 1.9.4
>=20
>=20
> On 6/16/05, Sean Kirkpatrick <Sea...@pi...> =
wrote:
> > We are currently in the process of QAing a release in which we will =
be
> > upgrading our production version of quickfix from 1.7.0 to 1.9.4.  =
When run on:=20
> >=20
> >         Linux 2.4.9-e.3 #1 Fri May 3 17:02:43 EDT 2002 i686=20
> >=20
> > our fix engine crashes whenever a FieldNotFound exception is thrown. =
 The
> > strange thing is that when the same binaries are used on my=20
> >=20
> >         Linux 2.4.21-27.0.1.ELsmp #1 SMP Mon Dec 20 18:47:45 EST =
2004 i686
> > i686 i386 GNU/Linux=20
> >=20
> > server, the exception is caught as expected.  Has anyone seen =
similar
> > behavior?  It definitely seems to indicate that there is some =
incompatibility, but I'm not
> > sure where...=20
>=20
> I've seen similar behavior when using incompatible versions of the GCC
> runtime library libgcc_s.so.1 (e.g. different GCC versions on the
> machine you compiled on and the libraries installed on the one you're
> running on)
>=20
> I'm not sure entirely what is in that library, but the exception
> handling code seems to be part of it.  You ought to be able to verify
> this with a simple test program that you compile on the newer machine
> and run on the older one.  Something like:
>=20
> simplethrow.cpp:
> #include <stdexcept>
> int main () {
>    try { throw std::runtime_error ("Boom!") }
>    catch (std::runtime_error) { return 0; }
>    return 1;
> }
>=20
> % g++ -g -o simplethrow simplethrow.cpp
>=20
> The program should exit cleanly with status 0:
>=20
> % ( ./simplethrow && echo w00t ) || echo uh-oh
> w00t
>=20
> You can likely work around the problem by putting a copy of the newer
> libgcc_s.so.1 (run ldd on your executable on the NEWER machine to find
> where it lives - probably /lib) into the directory where your QuickFIX
> .so lives, and ensuring this directory appears in your LD_LIBRARY_PATH
> before the directory where the system version lives.
>=20
> --=20
> Caleb Epstein
> caleb dot epstein at gmail dot com
>=20

Ok, so I am really banging my head on my desk at this point.

Thank you for the suggestions, Caleb.  I was able to run a simple
exception throwing program successfully.  The build server is running:

	Linux 2.4.9-e.3smp #1 SMP Fri May 3 16:48:54 EDT 2002 i686

The server having the issues is running:

	Linux 2.4.9-e.3 #1 Fri May 3 17:02:43 EDT 2002 i686

I have verified and re-verified that the binaries between these two
machines are identical.  It seems that the problem has something to do =
with
the new function declarations as "FieldNotFound" rather than=20
"FieldNotFound&".  I'm basing this on the call_unexpected that is being
triggered in the trace:

#0  0x40803b11 in __kill () from /lib/i686/libc.so.6
#1  0x406e079b in raise (sig=3D6) at signals.c:65
#2  0x40805092 in abort () at ../sysdeps/generic/abort.c:88
#3  0x40741247 in __cxxabiv1::__terminate(void (*)()) =
(handler=3D0x40804f34
	<abort>) at eh_terminate.cc:47
#4  0x40741100 in __cxa_call_unexpected (exc_obj_in=3D0x4) at =
eh_personality.cc:406
#5  0x407d1fdc in _Unwind_RaiseException_Phase2 (exc=3D0x84ab0f0, =
context=3D0x4150d0dc)=20
	at ../../gcc/unwind-dw2.c:1045
#6  0x407d2116 in _Unwind_RaiseException (exc=3D0x84ab0f0) at=20
	../../gcc/unwind-dw2.c:1045
#7  0x407413f9 in __cxa_throw (obj=3D0x84ab0f0, tinfo=3D0x8254048, =
dest=3D0x8254048)=20
	at eh_throw.cc:72
#8  0x08113fb5 in FIX::FieldMap::getField(FIX::FieldBase&) const =
(this=3D0x4150e7cc,
	field=3D@0x4150d5dc) at /usr/local/include/quickfix/FieldMap.h:101
#9  0x080c63d4 in ClientCode::FIXToNewOrder(Session*,
	FIX::Message const&, Order&) (this=3D0x81a30b0, pSession=3D0x8213a10,
	msg=3D@0x4150e7cc, order=3D@0x4150d90c) at qfmsg.cpp:1649
#10 0x080ce118 in ClientCode::FIXToNewOrder(Session*, FIX::Message =
const&, Order&)
	(this=3D0x81a30b0, pSession=3D0x8213a10, msg=3D@0x4150e7cc, =
order=3D@0x4150d90c) at 	qfmsg.cpp:2738
#11 0x080b3fed in ClientCode::OnNewOrderSingle(Session*, FIX::Message =
const&,
	FIX::BeginString const&) (this=3D0x81a30b0, pSession=3D0x8213a10, =
msg=3D@0x4150e7cc, 	beginString=3D@0x4150df2c) at qfmsg.cpp:573
#12 0x080ae1ef in ClientCode::OnFIXAppMessageIn(Session*, FIX::Message =
const&)
	(this=3D0x81a30b0,pSession=3D0x8213a10, msg=3D@0x4150e7cc) at =
qfmsg.cpp:231
#13 0x08096724 in ClientCode::fromApp(FIX::Message const&, =
FIX::SessionID const&)
	(this=3D0x81ba5b8,msg=3D@0x4150e7cc, sessionid=3D@0x84482dc) at =
qfeng.cpp:1291
#14 0x4039ae3b in FIX::Session::fromCallback(FIX::MsgType const&,
	FIX::Message const&, FIX::SessionID const&) (this=3D0x84482d8,
	msgType=3D@0x4150e22c, msg=3D@0x4150e7cc, sessionID=3D@0x84482dc) at
	Session.cpp:932
#15 0x4039a26f in FIX::Session::verify(FIX::Message const&, bool, bool)
	(this=3D0x84482d8, msg=3D@0x4150e7cc, checkTooHigh=3Dtrue, =
checkTooLow=3Dtrue)
	at Session.cpp:899
#16 0x4039e3f6 in FIX::Session::next(FIX::Message const&) =
(this=3D0x84482d8,
	message=3D@0x4150e7cc) at Session.cpp:1137
#17 0x4039d3cd in FIX::Session::next(_STL::basic_string<char,
	_STL::char_traits<char>, _STL::allocator<char> > const&) =
(this=3D0x84482d8,
	msg=3D@0x4150e89c) at Session.cpp:1071
#18 0x403bd59c in FIX::SocketConnection::read(FIX::SocketAcceptor&,
	FIX::SocketServer&) (this=3D0x8455e78, a=3D@0x8254048, s=3D@0x844eff0) =
at
	SocketConnection.cpp:112
#19 0x403b7a83 in FIX::SocketAcceptor::onData(FIX::SocketServer&, int)
	(this=3D0x8205db8, server=3D@0x844eff0, s=3D123) at =
SocketAcceptor.cpp:157
#20 0x4040b869 in FIX::ServerWrapper::onEvent(FIX::SocketMonitor&, int)
	(this=3D0x4150ea7c, socket=3D123) at SocketServer.cpp:60
#21 0x403bc9f8 in =
FIX::SocketMonitor::block(FIX::SocketMonitor::Strategy&,
	bool) (this=3D0x844f00c, strategy=3D@0x4150ea7c, poll=3Dfalse) at
	SocketMonitor.cpp:182
#22 0x403ae620 in FIX::SocketServer::block(FIX::SocketServer::Strategy&, =
bool)
	(this=3D0x844eff0, strategy=3D@0x8254048, poll=3Dfalse) at =
SocketServer.cpp:124
#23 0x403b771b in FIX::SocketAcceptor::onStart() (this=3D0x844eff0) at
	SocketAcceptor.cpp:84
#24 0x403b17f1 in FIX::Acceptor::startThread(void*) (p=3D0x8254048) at
	Acceptor.cpp:208
#25 0x406ddc6f in pthread_start_thread (arg=3D0x4150ebe0) at =
manager.c:284

It's lines 4-7 that seem suspicious to me, but I haven't been able to =
get
around this crash.  Any help would be greatly appreciated.

Thanks,
Sean


Additional Info:

We are using STLport 4.6.2 and I ran:
	./configure --with-stlport=3D/usr/local --disable-callstack
before building quickfix.  I also tried adding --enable-shared, after =
some
googling, but that didn't seem to make a difference...

Re: [Quickfix-developers] crash when upgrade to 1.9.4

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

On 6/20/05, Sean Kirkpatrick <Sea...@pi...> wrote:
=20
> Ok, so I am really banging my head on my desk at this point.
>=20
> Thank you for the suggestions, Caleb.  I was able to run a simple
> exception throwing program successfully.  The build server is running:
>=20
>         Linux 2.4.9-e.3smp #1 SMP Fri May 3 16:48:54 EDT 2002 i686
>=20
> The server having the issues is running:
>=20
>         Linux 2.4.9-e.3 #1 Fri May 3 17:02:43 EDT 2002 i686
>=20
> I have verified and re-verified that the binaries between these two
> machines are identical.  It seems that the problem has something to do wi=
th
> the new function declarations as "FieldNotFound" rather than
> "FieldNotFound&".  I'm basing this on the call_unexpected that is being
> triggered in the trace:
>=20
> #0  0x40803b11 in __kill () from /lib/i686/libc.so.6
> #1  0x406e079b in raise (sig=3D6) at signals.c:65
> #2  0x40805092 in abort () at ../sysdeps/generic/abort.c:88
> #3  0x40741247 in __cxxabiv1::__terminate(void (*)()) (handler=3D0x40804f=
34
>         <abort>) at eh_terminate.cc:47
> #4  0x40741100 in __cxa_call_unexpected (exc_obj_in=3D0x4) at eh_personal=
ity.cc:406
> #5  0x407d1fdc in _Unwind_RaiseException_Phase2 (exc=3D0x84ab0f0, context=
=3D0x4150d0dc)
>         at ../../gcc/unwind-dw2.c:1045
> #6  0x407d2116 in _Unwind_RaiseException (exc=3D0x84ab0f0) at
>         ../../gcc/unwind-dw2.c:1045
> #7  0x407413f9 in __cxa_throw (obj=3D0x84ab0f0, tinfo=3D0x8254048, dest=
=3D0x8254048)
>         at eh_throw.cc:72
> #8  0x08113fb5 in FIX::FieldMap::getField(FIX::FieldBase&) const (this=3D=
0x4150e7cc,
>         field=3D@0x4150d5dc) at /usr/local/include/quickfix/FieldMap.h:10=
1
> #9  0x080c63d4 in ClientCode::FIXToNewOrder(Session*,
>         FIX::Message const&, Order&) (this=3D0x81a30b0, pSession=3D0x8213=
a10,
>         msg=3D@0x4150e7cc, order=3D@0x4150d90c) at qfmsg.cpp:1649

Are you catching FIX::FieldNotFound (by value or reference) in your
code here (qfmsg.cpp:1649)?

--=20
Caleb Epstein
caleb dot epstein at gmail dot com

RE: [Quickfix-developers] crash when upgrade to 1.9.4

[Sean K. <Sea...@Pi...>]

> -----Original Message-----
> From: Caleb Epstein [mailto:cal...@gm...]
> Sent: Tuesday, June 21, 2005 11:30 AM
> To: Sean Kirkpatrick
> Cc: qui...@li...
> Subject: Re: [Quickfix-developers] crash when upgrade to 1.9.4
>=20
>=20
> On 6/20/05, Sean Kirkpatrick=20
> <Sea...@pi...> wrote:
> =20
> > Ok, so I am really banging my head on my desk at this point.
> >=20
> > Thank you for the suggestions, Caleb.  I was able to run a simple
> > exception throwing program successfully.  The build server=20
> is running:
> >=20
> >         Linux 2.4.9-e.3smp #1 SMP Fri May 3 16:48:54 EDT 2002 i686
> >=20
> > The server having the issues is running:
> >=20
> >         Linux 2.4.9-e.3 #1 Fri May 3 17:02:43 EDT 2002 i686
> >=20
> > I have verified and re-verified that the binaries between these two
> > machines are identical.  It seems that the problem has=20
> something to do with
> > the new function declarations as "FieldNotFound" rather than
> > "FieldNotFound&".  I'm basing this on the call_unexpected=20
> that is being
> > triggered in the trace:
> >=20
> > #0  0x40803b11 in __kill () from /lib/i686/libc.so.6
> > #1  0x406e079b in raise (sig=3D6) at signals.c:65
> > #2  0x40805092 in abort () at ../sysdeps/generic/abort.c:88
> > #3  0x40741247 in __cxxabiv1::__terminate(void (*)())=20
> (handler=3D0x40804f34
> >         <abort>) at eh_terminate.cc:47
> > #4  0x40741100 in __cxa_call_unexpected (exc_obj_in=3D0x4) at=20
> eh_personality.cc:406
> > #5  0x407d1fdc in _Unwind_RaiseException_Phase2=20
> (exc=3D0x84ab0f0, context=3D0x4150d0dc)
> >         at ../../gcc/unwind-dw2.c:1045
> > #6  0x407d2116 in _Unwind_RaiseException (exc=3D0x84ab0f0) at
> >         ../../gcc/unwind-dw2.c:1045
> > #7  0x407413f9 in __cxa_throw (obj=3D0x84ab0f0,=20
> tinfo=3D0x8254048, dest=3D0x8254048)
> >         at eh_throw.cc:72
> > #8  0x08113fb5 in FIX::FieldMap::getField(FIX::FieldBase&)=20
> const (this=3D0x4150e7cc,
> >         field=3D@0x4150d5dc) at=20
> /usr/local/include/quickfix/FieldMap.h:101
> > #9  0x080c63d4 in ClientCode::FIXToNewOrder(Session*,
> >         FIX::Message const&, Order&) (this=3D0x81a30b0,=20
> pSession=3D0x8213a10,
> >         msg=3D@0x4150e7cc, order=3D@0x4150d90c) at qfmsg.cpp:1649
>=20
> Are you catching FIX::FieldNotFound (by value or reference) in your
> code here (qfmsg.cpp:1649)?
>=20
> --=20
> Caleb Epstein
> caleb dot epstein at gmail dot com
>=20

I actually originally had it caught by ref, then tried by val, and
have since changed it back to by ref.

[Quickfix-developers] QuickFIX Engine overall performance

[Barry M. <bar...@ya...>]

Are there any available measurements for the Quick FIX engine
that address overall performance, for instance

- Message Rates
  - Outgoing Message Rates
  - Incoming Message Rates
  - Average of Outgoing and Incoming message rates

- XML format versus tag=value format

- Platform-specific performance measurements
  - Linux
  - Solaris
  - Windows

Thanks,
Barry

Email: Barry Marks <bar...@ya...>
 

RE: [Quickfix-developers] crash when upgrade to 1.9.4

[Sean K. <Sea...@Pi...>]

See below.

> -----Original Message-----
> From: Caleb Epstein [mailto:cal...@gm...]
> Sent: Thursday, June 16, 2005 6:02 PM
> To: Sean Kirkpatrick
> Cc: qui...@li...
> Subject: Re: [Quickfix-developers] crash when upgrade to 1.9.4
>=20
>=20
> On 6/16/05, Sean Kirkpatrick <Sea...@pi...> =
wrote:
> > We are currently in the process of QAing a release in which we will =
be
> > upgrading our production version of quickfix from 1.7.0 to 1.9.4.  =
When run on:=20
> >=20
> >         Linux 2.4.9-e.3 #1 Fri May 3 17:02:43 EDT 2002 i686=20
> >=20
> > our fix engine crashes whenever a FieldNotFound exception is thrown. =
 The
> > strange thing is that when the same binaries are used on my=20
> >=20
> >         Linux 2.4.21-27.0.1.ELsmp #1 SMP Mon Dec 20 18:47:45 EST =
2004 i686
> > i686 i386 GNU/Linux=20
> >=20
> > server, the exception is caught as expected.  Has anyone seen =
similar
> > behavior?  It definitely seems to indicate that there is some =
incompatibility, but I'm not
> > sure where...=20
>=20
> I've seen similar behavior when using incompatible versions of the GCC
> runtime library libgcc_s.so.1 (e.g. different GCC versions on the
> machine you compiled on and the libraries installed on the one you're
> running on)
>=20
> I'm not sure entirely what is in that library, but the exception
> handling code seems to be part of it.  You ought to be able to verify
> this with a simple test program that you compile on the newer machine
> and run on the older one.  Something like:
>=20
> simplethrow.cpp:
> #include <stdexcept>
> int main () {
>    try { throw std::runtime_error ("Boom!") }
>    catch (std::runtime_error) { return 0; }
>    return 1;
> }
>=20
> % g++ -g -o simplethrow simplethrow.cpp
>=20
> The program should exit cleanly with status 0:
>=20
> % ( ./simplethrow && echo w00t ) || echo uh-oh
> w00t
>=20
> You can likely work around the problem by putting a copy of the newer
> libgcc_s.so.1 (run ldd on your executable on the NEWER machine to find
> where it lives - probably /lib) into the directory where your QuickFIX
> .so lives, and ensuring this directory appears in your LD_LIBRARY_PATH
> before the directory where the system version lives.
>=20
> --=20
> Caleb Epstein
> caleb dot epstein at gmail dot com
>=20

Ok, so I am really banging my head on my desk at this point.

Thank you for the suggestions, Caleb.  I was able to run a simple
exception throwing program successfully.  The build server is running:

	Linux 2.4.9-e.3smp #1 SMP Fri May 3 16:48:54 EDT 2002 i686

The server having the issues is running:

	Linux 2.4.9-e.3 #1 Fri May 3 17:02:43 EDT 2002 i686

I have verified and re-verified that the binaries between these two
machines are identical.  It seems that the problem has something to do =
with
the new function declarations as "FieldNotFound" rather than=20
"FieldNotFound&".  I'm basing this on the call_unexpected that is being
triggered in the trace:

#0  0x40803b11 in __kill () from /lib/i686/libc.so.6
#1  0x406e079b in raise (sig=3D6) at signals.c:65
#2  0x40805092 in abort () at ../sysdeps/generic/abort.c:88
#3  0x40741247 in __cxxabiv1::__terminate(void (*)()) =
(handler=3D0x40804f34
	<abort>) at eh_terminate.cc:47
#4  0x40741100 in __cxa_call_unexpected (exc_obj_in=3D0x4) at =
eh_personality.cc:406
#5  0x407d1fdc in _Unwind_RaiseException_Phase2 (exc=3D0x84ab0f0, =
context=3D0x4150d0dc)=20
	at ../../gcc/unwind-dw2.c:1045
#6  0x407d2116 in _Unwind_RaiseException (exc=3D0x84ab0f0) at=20
	../../gcc/unwind-dw2.c:1045
#7  0x407413f9 in __cxa_throw (obj=3D0x84ab0f0, tinfo=3D0x8254048, =
dest=3D0x8254048)=20
	at eh_throw.cc:72
#8  0x08113fb5 in FIX::FieldMap::getField(FIX::FieldBase&) const =
(this=3D0x4150e7cc,
	field=3D@0x4150d5dc) at /usr/local/include/quickfix/FieldMap.h:101
#9  0x080c63d4 in ClientCode::FIXToNewOrder(Session*,
	FIX::Message const&, Order&) (this=3D0x81a30b0, pSession=3D0x8213a10,
	msg=3D@0x4150e7cc, order=3D@0x4150d90c) at qfmsg.cpp:1649
#10 0x080ce118 in ClientCode::FIXToNewOrder(Session*, FIX::Message =
const&, Order&)
	(this=3D0x81a30b0, pSession=3D0x8213a10, msg=3D@0x4150e7cc, =
order=3D@0x4150d90c) at 	qfmsg.cpp:2738
#11 0x080b3fed in ClientCode::OnNewOrderSingle(Session*, FIX::Message =
const&,
	FIX::BeginString const&) (this=3D0x81a30b0, pSession=3D0x8213a10, =
msg=3D@0x4150e7cc, 	beginString=3D@0x4150df2c) at qfmsg.cpp:573
#12 0x080ae1ef in ClientCode::OnFIXAppMessageIn(Session*, FIX::Message =
const&)
	(this=3D0x81a30b0,pSession=3D0x8213a10, msg=3D@0x4150e7cc) at =
qfmsg.cpp:231
#13 0x08096724 in ClientCode::fromApp(FIX::Message const&, =
FIX::SessionID const&)
	(this=3D0x81ba5b8,msg=3D@0x4150e7cc, sessionid=3D@0x84482dc) at =
qfeng.cpp:1291
#14 0x4039ae3b in FIX::Session::fromCallback(FIX::MsgType const&,
	FIX::Message const&, FIX::SessionID const&) (this=3D0x84482d8,
	msgType=3D@0x4150e22c, msg=3D@0x4150e7cc, sessionID=3D@0x84482dc) at
	Session.cpp:932
#15 0x4039a26f in FIX::Session::verify(FIX::Message const&, bool, bool)
	(this=3D0x84482d8, msg=3D@0x4150e7cc, checkTooHigh=3Dtrue, =
checkTooLow=3Dtrue)
	at Session.cpp:899
#16 0x4039e3f6 in FIX::Session::next(FIX::Message const&) =
(this=3D0x84482d8,
	message=3D@0x4150e7cc) at Session.cpp:1137
#17 0x4039d3cd in FIX::Session::next(_STL::basic_string<char,
	_STL::char_traits<char>, _STL::allocator<char> > const&) =
(this=3D0x84482d8,
	msg=3D@0x4150e89c) at Session.cpp:1071
#18 0x403bd59c in FIX::SocketConnection::read(FIX::SocketAcceptor&,
	FIX::SocketServer&) (this=3D0x8455e78, a=3D@0x8254048, s=3D@0x844eff0) =
at
	SocketConnection.cpp:112
#19 0x403b7a83 in FIX::SocketAcceptor::onData(FIX::SocketServer&, int)
	(this=3D0x8205db8, server=3D@0x844eff0, s=3D123) at =
SocketAcceptor.cpp:157
#20 0x4040b869 in FIX::ServerWrapper::onEvent(FIX::SocketMonitor&, int)
	(this=3D0x4150ea7c, socket=3D123) at SocketServer.cpp:60
#21 0x403bc9f8 in =
FIX::SocketMonitor::block(FIX::SocketMonitor::Strategy&,
	bool) (this=3D0x844f00c, strategy=3D@0x4150ea7c, poll=3Dfalse) at
	SocketMonitor.cpp:182
#22 0x403ae620 in FIX::SocketServer::block(FIX::SocketServer::Strategy&, =
bool)
	(this=3D0x844eff0, strategy=3D@0x8254048, poll=3Dfalse) at =
SocketServer.cpp:124
#23 0x403b771b in FIX::SocketAcceptor::onStart() (this=3D0x844eff0) at
	SocketAcceptor.cpp:84
#24 0x403b17f1 in FIX::Acceptor::startThread(void*) (p=3D0x8254048) at
	Acceptor.cpp:208
#25 0x406ddc6f in pthread_start_thread (arg=3D0x4150ebe0) at =
manager.c:284

It's lines 4-7 that seem suspicious to me, but I haven't been able to =
get
around this crash.  Any help would be greatly appreciated.

Thanks,
Sean

Re: [Quickfix-developers] Logon retry interval

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

Use the ReconnectInterval setting.

--oren
  ----- Original Message -----=20
  From: Alvin Wang=20
  To: qui...@li... ; =
qui...@li...=20
  Cc: Oren Miller=20
  Sent: Friday, June 17, 2005 3:43 PM
  Subject: [Quickfix-developers] Logon retry interval



  Hi,=20

  Can I configure the logon retry interval? It is 40 sec in my QF. I do =
not know where it comes from. It seems not heartbeat interval.=20

  Thanks=20
  Alvin =
********************************************************************** =
This e-mail message is intended solely for the use of the addressee. The =
message may contain information that is privileged and confidential. =
Disclosure to anyone other than the intended recipient is prohibited. If =
you are not the intended recipient, please do not disseminate, =
distribute or copy this communication, by e-mail or otherwise. Instead, =
please notify us immediately by return e-mail (including the original =
message with your reply) and then delete and discard all copies of the =
message. We have taken precautions to minimize the risk of transmitting =
software viruses but nevertheless advise you to carry out your own virus =
checks on any attachment to this message. We accept no liability for any =
loss or damage caused by software viruses. =
********************************************************************** 

[Quickfix-developers] Logon retry interval

[Alvin W. <AW...@FF...>]

Hi,

Can I configure the logon retry interval? It is 40 sec in my QF. I do not 
know where it comes from. It seems not heartbeat interval.

Thanks
Alvin
                                                                                                                                                                                                                                                                                                    **********************************************************************
This e-mail message is intended solely for the use of the addressee.
The message may contain information that is privileged and confidential.  
Disclosure to anyone other than the intended recipient is
prohibited. If you are not the intended recipient, please do not
disseminate, distribute or copy this communication, by e-mail or
otherwise. Instead, please notify us immediately by return e-mail
(including the original message with your reply) and then delete
and discard all copies of the message. We have taken precautions to
minimize the risk of transmitting software viruses but nevertheless
advise you to carry out your own virus checks on any attachment to
this message.  We accept no liability for any loss or damage caused
by software viruses.
**********************************************************************

Re: [Quickfix-developers] RE: Logout reason

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

Oren Miller wrote:
> I've found your patch from your earlier posting.  It just slipped 
> through the cracks.  I'll get it in.  Usually if you want to make sure 
> that something doesn't slip through it's best to add it to the 
> bugtracker: http://www.quickfixengine.org/bugtracker/

In addition, it would be very good to have such a "what"-argument in the Session.logout() 
method. Since logout() just sets the member variable m_enabled to false, the logout reason 
has to be provided in some other member, ie m_logout_reason? What do you think, Oren?

> I added an issue for this to make sure it won't slip again: 
> http://www.quickfixengine.org/bugtracker/bug.php?op=show&bugid=80&pos=

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

Cheers, Jörg

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

Re: [Quickfix-developers] crash when upgrade to 1.9.4

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

On 6/16/05, Sean Kirkpatrick <Sea...@pi...> wrote:
> We are currently in the process of QAing a release in which we will be
> upgrading our production version of quickfix from 1.7.0 to 1.9.4.  When r=
un on:=20
>=20
>         Linux 2.4.9-e.3 #1 Fri May 3 17:02:43 EDT 2002 i686=20
>=20
> our fix engine crashes whenever a FieldNotFound exception is thrown.  The
> strange thing is that when the same binaries are used on my=20
>=20
>         Linux 2.4.21-27.0.1.ELsmp #1 SMP Mon Dec 20 18:47:45 EST 2004 i68=
6
> i686 i386 GNU/Linux=20
>=20
> server, the exception is caught as expected.  Has anyone seen similar
> behavior?  It definitely seems to indicate that there is some incompatibi=
lity, but I'm not
> sure where...=20

I've seen similar behavior when using incompatible versions of the GCC
runtime library libgcc_s.so.1 (e.g. different GCC versions on the
machine you compiled on and the libraries installed on the one you're
running on)

I'm not sure entirely what is in that library, but the exception
handling code seems to be part of it.  You ought to be able to verify
this with a simple test program that you compile on the newer machine
and run on the older one.  Something like:

simplethrow.cpp:
#include <stdexcept>
int main () {
   try { throw std::runtime_error ("Boom!") }
   catch (std::runtime_error) { return 0; }
   return 1;
}

% g++ -g -o simplethrow simplethrow.cpp

The program should exit cleanly with status 0:

% ( ./simplethrow && echo w00t ) || echo uh-oh
w00t

You can likely work around the problem by putting a copy of the newer
libgcc_s.so.1 (run ldd on your executable on the NEWER machine to find
where it lives - probably /lib) into the directory where your QuickFIX
.so lives, and ensuring this directory appears in your LD_LIBRARY_PATH
before the directory where the system version lives.

--=20
Caleb Epstein
caleb dot epstein at gmail dot com

[Quickfix-developers] crash when upgrade to 1.9.4

[Sean K. <Sea...@Pi...>]

Hello All,

We are currently in the process of QAing a release in which we will be =
upgrading our=20
production version of quickfix from 1.7.0 to 1.9.4.  When run on:

	Linux 2.4.9-e.3 #1 Fri May 3 17:02:43 EDT 2002 i686

our fix engine crashes whenever a FieldNotFound exception is thrown.  =
The strange thing=20
is that when the same binaries are used on my

	Linux 2.4.21-27.0.1.ELsmp #1 SMP Mon Dec 20 18:47:45 EST 2004 i686 i686 =

		i386 GNU/Linux

server, the exception is caught as expected.  Has anyone seen similar =
behavior?  It
definitely seems to indicate that there is some incompatibility, but I'm =
not sure where...

An easy way to consistently reproduce the issue is to submit a 4.2 order =
without an
OrderQty set.

Any help will be greatly appreciated.  Thanks!

--Sean

Re: [Quickfix-developers] FileStore access

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

On 6/16/05, Nikhil Bose <ass...@ya...> wrote:

> How do I access / retrieve these messages in my application.  In other
> words, how do I get a FileStore object to retrieve outgoing messages?  Ar=
e
> these classes thread-safe?=20

You can get at the MessageStore directly from Session::getStore, but
the "get" method on this objetc is not synchronized.  Best bet would
be to get the Session's SessionState object via something like
(minimally tested):

    SessionState* state =3D dynamic_cast<SessionState*> (session->getLog ()=
);

And then use the SessionState's "get" method, which *is* synchronized
and is also what the Session layer uses itself, so you can be sure
nothing will get corrupted.

--=20
Caleb Epstein
caleb dot epstein at gmail dot com

[Quickfix-developers] FileStore access

[Nikhil B. <ass...@ya...>]

Hello,
 
I am using a FileStoreFactory() to create a FileStore to persist outgoing messages.
 
How do I access / retrieve these messages in my application.  In other words, how do I get a FileStore object to retrieve outgoing messages?  Are these classes thread-safe?
 
Thanks,
Nikhil
 

Re: [Quickfix-developers] RE: Logout reason

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

Thanks Brian, I wasn't aware of this field.

I've found your patch from your earlier posting.  It just slipped through 
the cracks.  I'll get it in.  Usually if you want to make sure that 
something doesn't slip through it's best to add it to the bugtracker: 
http://www.quickfixengine.org/bugtracker/

I added an issue for this to make sure it won't slip again: 
http://www.quickfixengine.org/bugtracker/bug.php?op=show&bugid=80&pos=

--oren

----- Original Message ----- 
From: "Brian Erst" <azz...@ya...>
To: "Oren Miller" <or...@qu...>; "Francis Gingras" 
<fr...@at...>; <qui...@li...>
Sent: Thursday, June 16, 2005 1:12 PM
Subject: Re: [Quickfix-developers] RE: Logout reason


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 -

Some people have been using tag 789 (NextExpectedMsgSeqNum), introduced
in FIX 4.4, as a way to handle sequence number too low problems (the
CME does this).

Although it's still not a FIX standard (the FIX 4.4 use of this tag is
optional and on Logon messages only, but may become mandatory in 4.5),
it's a really nice way to recover from these situations. The acceptor,
when detecting a message too low, sends a Logout message with tag 789
set to the expected sequence number. The initiator can then adjust its
sequence number and attempt to log in again.

It's a lot cleaner way of recovering from a catastrophic client-side
failure than resetting both sequence numbers. If the initiator had some
sort of problem that prevents it from being able to resend any gaps,
but does NOT want to miss any gaps on the acceptor side, it's really
the only clean solution. In most cases, the initiator is definitely
going to want the ExecutionReports that have queued up since its
failure, but may not have the messages that were sent prior to its
failure (or may not want to send them - stale order messages are
potentially a HUGE risk, so why submit them?).

The use of this tag is VERY popular among the developers that are
connecting to my system and has been equally well-received by the CME
community. Hopefully, its use will be picked up in 4.5.

Speaking of logouts, I haven't noticed any changes to Session.cpp in
regards to using the "what" string in RejectLogon to populate the Text
field in a Logout message. You seemed to think it was a good idea last
month - I could resend the patch if you want (I haven't really done
much with CVS and the patch is trivial).

- Brian Erst
Thynk Software, Inc.

--- Oren Miller <or...@qu...> 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
>
> Yeah, this behavior is actually what the FPL recommends.  When
> receiving a
> sequence number that is too low, you are supposed to kill the
> connection
> because there isn't really anything you can do automatically.  In
> fact I
> believe this is the one scenario where the protocol document states
> that
> manual intervention is required.  Here is the exact quote: "If the
> incoming
> message has a sequence number less than expected and the PossDupFlag
> is not
> set, it indicates a serious error.  It is strongly recommended that
> the
> session be terminated and manual intervention be initiated."
>
> So really the third party engine is doing the right thing.  You'll
> find that
> QF would do exact same thing in this situation.
>
> If you really want to start the sequence numbers from scratch, you
> should
> reset you sequence numbers and send your logon with the ResetSeqNum
> flag.
> This can result in loss of messages if you are not careful.
>
> --oren
>
> ----- Original Message ----- 
> From: "Francis Gingras" <fr...@at...>
> To: <qui...@li...>
> Sent: Wednesday, June 15, 2005 7:35 PM
> Subject: [Quickfix-developers] RE: Logout reason
>
>
> > 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,
> >
> > You're right QF did send a resend request but the counterparty
> closed the
> > socket so I didn't notice.  (see log below)
> >
> > The "sequence number too high" message is from the client
> (initiator)
> > point
> > of view.  It appears that the counterparty does not send a logoff
> or a
> > session rejection message; it just closes the socket when it
> receives a
> > MsgSeqNum that is lower than what it expects.  BTW it's not a QF
> acceptor
> > but a custom 3rd party server.
> >
> > This is why the only solution I see is to increase the
> > setNextSenderMsgSeqNum by 1000 every time the socket drops during
> logon,
> > but
> > I'm not comfortable with such a kludge; what if there are other
> conditions
> > that cause the socket to drop?  Comments welcome.
> >
> > So to conclude, it does not appear to be a QF issue after all
> because the
> > acceptor side does not send any notification that the logon failed.
> >
> > 20050613-20:26:19 : Created session
> > 20050613-20:26:19 : Connecting to 127.0.0.1 on port 10501
> > 20050613-20:26:19 : Connection succeeded
> > 20050613-20:26:19 : Initiated logon request
> > 20050613-20:26:19 : Received logon response
> > 20050613-20:26:19 : MsgSeqNum too high, expecting  1 but received
> 481
> > 20050613-20:26:19 : Socket Error: Connection reset by peer.
> > 20050613-20:26:19 : Disconnecting
> > 20050613-20:26:19 : Sent ResendRequest FROM: 1 TO: 0
> >
> > Thanks,
> >
> > Francis
> >
> >
> >
> >
> > -------------------------------------------------------
> > SF.Net email is sponsored by: Discover Easy Linux Migration
> Strategies
> > from IBM. Find simple to follow Roadmaps, straightforward articles,
> > informative Webcasts and more! Get everything you need to get up to
> > speed, fast.
> http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> > _______________________________________________
> > Quickfix-developers mailing list
> > Qui...@li...
> > https://lists.sourceforge.net/lists/listinfo/quickfix-developers
> >
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration
> Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers