quickfix-users — QuickFIX user support

[Quickfix-users] header file voodoo

[H. S. <st...@un...>]

hi guys, hi oren,

i just encountered some header file voodoo while upgrading to 1.10.2
seems like gcc does not like initialization order. this was on FreeBSD 5.3-RELEASE-p5. 
i was not aware if changing stuff there breaks something else, so i decided to ask on the list before doing anything.


---- SNIP ----
In file included from /usr/local/quickfix/include/quickfix/Session.h:29,
                 from quickfix.h:42,
                 from opusfix.c:19:
/usr/local/quickfix/include/quickfix/SessionState.h: In constructor `FIX::SessionState::SessionState()':
/usr/local/quickfix/include/quickfix/SessionState.h:189: warning: `FIX::SessionState::m_sentReset' will be initialized after
/usr/local/quickfix/include/quickfix/SessionState.h:188: warning:   `bool FIX::SessionState::m_receivedReset'
/usr/local/quickfix/include/quickfix/SessionState.h:47: warning:   when initialized here
/usr/local/quickfix/include/quickfix/SessionState.h:200: warning: `FIX::SessionState::m_pLog' will be initialized after
/usr/local/quickfix/include/quickfix/SessionState.h:193: warning:   `int FIX::SessionState::m_resendRequested'
/usr/local/quickfix/include/quickfix/SessionState.h:47: warning:   when initialized here




regards,
heri








-- 
This e-mail may contain confidential and/or privileged information. 
If you are not the intended recipient (or have received this e-mail in error) 
please notify the sender immediately and destroy this e-mail. Any unauthorized 
copying, disclosure or distribution of the material in this e-mail is strictly 
forbidden.

Re: [Quickfix-users] Unix version compile under FreeBSD

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

Looks like there is a problem with the configure.in used to generate  
the build scripts.  I'm seeing the following:

     freebsd2*|freebsd3*|freebsd4*)
         LIBS="-pthread $LIBS"
         AC_MSG_RESULT([-pthread])
         ;;
     freebsdelf4*)
         LIBS="-pthread $LIBS"
         AC_MSG_RESULT([-pthread])
         ;;

This should probably be changed to just this:

     freebsd*)
         LIBS="-pthread $LIBS"
         AC_MSG_RESULT([-pthread])
         ;;

After making that change try running the bootstrap script to  
regenerate the build scripts and try again.  This should ensure that  
all versions of freebsd get the -pthread flag which is required to  
link to the pthread library.

--oren

On Jul 28, 2005, at 4:46 PM, CASALE, JOURDAIN (TORONTO) wrote:

> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/ 
> html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Hello,
>
> I'm having a rough time compiling under FreeBSD 5.4. This happens  
> if I try to compile with or without the --with-mysql or --with- 
> stlport. All the necessary dependencies (i.e. libxml2) appear to be  
> in place. The compile always crashes at the same point on two  
> different servers (AMD 64 and Xeon 32 bit).
>
> Here is the exact output I get:
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> g++ -shared -nostdlib /usr/lib/crti.o /usr/lib/crtbeginS.o libs/ 
> Session.o .libs/SessionTime.o .libs/SessionFactory.o .
> libs/Parser.o .libs/Log.o .libs/FileLog.o .libs/Settings.o .
> libs/ConfigLexer.o .libs/MessageStore.o .libs/SocketServer.o .
> libs/SocketConnector.o .libs/Acceptor.o .libs/Initiator.o .
> libs/SocketAcceptor.o .libs/SocketInitiator.o .libs/SocketMonitor.o .
> libs/SocketConnection.o .libs/ThreadedSocketAcceptor.o .
> libs/ThreadedSocketInitiator.o .libs/ThreadedSocketConnection.o .
> libs/FileStore.o .libs/MySQLStore.o .libs/MySQLLog.o .libs/ 
> Dictionary.o .
> libs/DataDictionary.o .libs/SessionSettings.o .libs/FieldTypes.o .
> libs/FieldMap.o .libs/Message.o .libs/Group.o .libs/MessageSorters.o .
> libs/Utility.o .libs/LIBXML_DOMDocument.o .libs/CallStack.o  - 
> lcompat .
> -L/usr/local/lib -lxml2 -lz -liconv -L/usr/lib -lstdc++ -lm - 
> lgcc_pic /usr/lib/crtendS.o /usr/lib/crtn.o  -Wl,-soname - 
> Wl,libquickfix.so.6 -o libs/libquickfix.so.6.
> (cd .libs && rm -f libquickfix.so && ln -s libquickfix.so.6  
> libquickfix.so)
> (cd .libs && rm -f libquickfix.so && ln -s libquickfix.so.6  
> libquickfix.so)
> creating libquickfix.la
> (cd .libs && rm -f libquickfix.la && ln -s ../libquickfix.la  
> libquickfix.la)
> rm -rf ../../lib/libquickfix.a
> rm -rf ../../lib/libquickfix.la
> rm -rf ../../lib/libquickfix.so
> rm -rf ../../lib/libquickfix.dylib
> ln -s ../src/C++/.libs/libquickfix.a ../../lib/libquickfix.a
> ln -s ../src/C++/.libs/libquickfix.la ../../lib/libquickfix.la
> ln -s ../src/C++/.libs/libquickfix.so ../../lib/libquickfix.so
> ln -s ../src/C++/.libs/libquickfix.dylib ../../lib/libquickfix.dylib
> bash ./copy.sh ../../include/quickfix *.h
> bash ./copy.sh ../../include/quickfix fix*/*.h
> if g++ -DHAVE_CONFIG_H -I. -I. -I.. -IC++     -g -O2 -I/usr/local/ 
> include/libxml2 -I/usr/local/include -MT at.o -MD -MP -MF ".deps/ 
> at.Tpo"  -c -o at.o `test -f 'at.cpp' || echo './'`at.cpp;  then mv  
> ".deps/at.Tpo" ".deps/at.Po";  else rm -f ".deps/at.Tpo"; exit 1;  fi
> /usr/local/bin/bash ../libtool --mode=link g++  -g -O2 -I/usr/local/ 
> include/libxml2 -I/usr/local/include    -o at  at.o C++/ 
> libquickfix.la -lc_r -lcompat   -L/usr/local/lib -lxml2 -lz -L/usr/ 
> local/lib -liconv -lm
> mkdir .libs
> g++ -g -O2 -I/usr/local/include/libxml2 -I/usr/local/include - 
> o .libs/at at.o  C++/.libs/libquickfix.so -L/usr/local/lib -lcompat  
> -lxml2 -lz -liconv -lm -Wl,--rpath -Wl,/usr/local/lib
> C++/.libs/libquickfix.so: undefined reference to `pthread_detach'
> C++/.libs/libquickfix.so: undefined reference to `pthread_join'
> C++/.libs/libquickfix.so: undefined reference to  
> `pthread_cond_timedwait'
> *** Error code 1
>
> Stop in /root/quickfix/src.
> *** Error code 1
>
> Stop in /root/quickfix/src.
> *** Error code 1
>
> Stop in /root/quickfix.
> *** Error code 1
>
> Stop in /root/quickfix.
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Are there any questions or log files that will help debug this?
>
> Thanks,
> Jourdain
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO  
> September
> 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams *  
> Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/ 
> bsce5sf
> _______________________________________________
> Quickfix-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-users
>
>

[Quickfix-users] Unix version compile under FreeBSD

[CASALE, J. (TORONTO) <jou...@si...>]

Hello,

I'm having a rough time compiling under FreeBSD 5.4. This happens if I 
try to compile with or without the --with-mysql or --with-stlport. All 
the necessary dependencies (i.e. libxml2) appear to be in place. The 
compile always crashes at the same point on two different servers (AMD 
64 and Xeon 32 bit).

Here is the exact output I get:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
g++ -shared -nostdlib /usr/lib/crti.o /usr/lib/crtbeginS.o 
.libs/Session.o .libs/SessionTime.o .libs/SessionFactory.o 
.libs/Parser.o .libs/Log.o .libs/FileLog.o .libs/Settings.o 
.libs/ConfigLexer.o .libs/MessageStore.o .libs/SocketServer.o 
.libs/SocketConnector.o .libs/Acceptor.o .libs/Initiator.o 
.libs/SocketAcceptor.o .libs/SocketInitiator.o .libs/SocketMonitor.o 
.libs/SocketConnection.o .libs/ThreadedSocketAcceptor.o 
.libs/ThreadedSocketInitiator.o .libs/ThreadedSocketConnection.o 
.libs/FileStore.o .libs/MySQLStore.o .libs/MySQLLog.o .libs/Dictionary.o 
.libs/DataDictionary.o .libs/SessionSettings.o .libs/FieldTypes.o 
.libs/FieldMap.o .libs/Message.o .libs/Group.o .libs/MessageSorters.o 
.libs/Utility.o .libs/LIBXML_DOMDocument.o .libs/CallStack.o  -lcompat 
-L/usr/local/lib -lxml2 -lz -liconv -L/usr/lib -lstdc++ -lm -lgcc_pic 
/usr/lib/crtendS.o /usr/lib/crtn.o  -Wl,-soname -Wl,libquickfix.so.6 -o 
.libs/libquickfix.so.6
(cd .libs && rm -f libquickfix.so && ln -s libquickfix.so.6 libquickfix.so)
(cd .libs && rm -f libquickfix.so && ln -s libquickfix.so.6 libquickfix.so)
creating libquickfix.la
(cd .libs && rm -f libquickfix.la && ln -s ../libquickfix.la libquickfix.la)
rm -rf ../../lib/libquickfix.a
rm -rf ../../lib/libquickfix.la
rm -rf ../../lib/libquickfix.so
rm -rf ../../lib/libquickfix.dylib
ln -s ../src/C++/.libs/libquickfix.a ../../lib/libquickfix.a
ln -s ../src/C++/.libs/libquickfix.la ../../lib/libquickfix.la
ln -s ../src/C++/.libs/libquickfix.so ../../lib/libquickfix.so
ln -s ../src/C++/.libs/libquickfix.dylib ../../lib/libquickfix.dylib
bash ./copy.sh ../../include/quickfix *.h
bash ./copy.sh ../../include/quickfix fix*/*.h
if g++ -DHAVE_CONFIG_H -I. -I. -I.. -IC++     -g -O2 
-I/usr/local/include/libxml2 -I/usr/local/include -MT at.o -MD -MP -MF 
".deps/at.Tpo"  -c -o at.o `test -f 'at.cpp' || echo './'`at.cpp;  then 
mv ".deps/at.Tpo" ".deps/at.Po";  else rm -f ".deps/at.Tpo"; exit 1;  fi
/usr/local/bin/bash ../libtool --mode=link g++  -g -O2 
-I/usr/local/include/libxml2 -I/usr/local/include    -o at  at.o 
C++/libquickfix.la -lc_r -lcompat   -L/usr/local/lib -lxml2 -lz 
-L/usr/local/lib -liconv -lm
mkdir .libs
g++ -g -O2 -I/usr/local/include/libxml2 -I/usr/local/include -o .libs/at 
at.o  C++/.libs/libquickfix.so -L/usr/local/lib -lcompat -lxml2 -lz 
-liconv -lm -Wl,--rpath -Wl,/usr/local/lib
C++/.libs/libquickfix.so: undefined reference to `pthread_detach'
C++/.libs/libquickfix.so: undefined reference to `pthread_join'
C++/.libs/libquickfix.so: undefined reference to `pthread_cond_timedwait'
*** Error code 1

Stop in /root/quickfix/src.
*** Error code 1

Stop in /root/quickfix/src.
*** Error code 1

Stop in /root/quickfix.
*** Error code 1

Stop in /root/quickfix.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Are there any questions or log files that will help debug this?

Thanks,
Jourdain

[Quickfix-users] DualLogFactory implementation in C# using Joerg Thoennes example

[George G. <gge...@ho...>]

In case somebody needs to do the same thing in C#
this is how I have done it.

using System;
using QuickFix;

namespace Utils
{
/// <summary>
/// Summary description for DualLogFactory.
/// </summary>
public class DualLogFactory: QuickFix.LogFactory
{
private QuickFix.LogFactory lf1;
private QuickFix.LogFactory lf2;

public DualLogFactory( QuickFix.LogFactory lf1, QuickFix.LogFactory lf2 )
{
this.lf1 = lf1;
this.lf2 = lf2;
}
public QuickFix.Log create( SessionID sessionID )
{
return new DualLog( lf1.create( sessionID ), lf2.create( sessionID ) );
}
}
}



using System;
using QuickFix;

namespace Utils
{
/// <summary>
/// Summary description for DualLog.
/// </summary>
public class DualLog: QuickFix.Log
{
QuickFix.Log l1;
QuickFix.Log l2;
public DualLog( QuickFix.Log l1, QuickFix.Log l2 )
{
this.l1 = l1;
this.l2 = l2;
}

public void onIncoming( String text )
{
l1.onIncoming( text );
l2.onIncoming( text );
}

public void onOutgoing( String text )
{
l1.onOutgoing( text );
l2.onOutgoing( text );
}

public void onEvent( String text )
{
l1.onEvent( text );
l2.onEvent( text );
}

}
}


//called like this from main part
FileLogFactory fileLogFactory = new FileLogFactory( settings );
ScreenLogFactory screenLogFactory = new ScreenLogFactory( true, true, true 
);
DualLogFactory dualLogFactory = new 
DualLogFactory(fileLogFactory,screenLogFactory);

SocketInitiator initiator = new SocketInitiator( fixApp,
		factory, settings, dualLogFactory, messageFactory );

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Re: [Quickfix-users] QuickFIX/J Beta 1 Available

[Nick E. <ni...@de...>]

Hi,

I'm sorry, but I forgot to do this... Actually (regarding this particular
usecase) according to quickfix termination message:

terminate called after throwing an instance of 'std::logic_error'
  what():  Tried to send a reject while not logged on

termination seems to be caused by broken logic in Session.cpp.


> Nick Evgeniev wrote:
>> It's a greate news! Hopefully it would not coredump on every broken logon
>> request as jni version does!
>
> If you do not add any native stuff... ;-)
>
> But seriously: Did you report these coredumps via the bugtracker? I
> remember some mailings from you in the end of June.
>
> Cheers, Jörg
>
> -- 
> Joerg Thoennes
>                                http://macd.com
> Tel.: +49 (0)241 44597-24      Macdonald Associates GmbH
> Fax : +49 (0)241 44597-10      Lothringer Str. 52, D-52070 Aachen

[Quickfix-users] RE: [Quickfix-developers] QuickFIX/J Beta 1 Available

[David V. <dvi...@sm...>]

Hi RK,

Will be happy to share experiences with the other workers.

The Mbeans (Sessions, Statistics) are working on JB 3.2.7, 4.O and MX4J
3.0...

Cheers

David

-----Message d'origine-----
De=A0: VP Marketing IT Asset Enterprise Technologies
[mailto:ass...@gm...]=20
Envoy=E9=A0: jeudi 21 juillet 2005 20:22
=C0=A0: David VINCENT
Cc=A0: Joerg Thoennes; Steve Bate; =
qui...@li...;
qui...@li...
Objet=A0: Re: [Quickfix-developers] QuickFIX/J Beta 1 Available

Hi David

There were a few others who did work and have posted msgs on the
list.

Later I will send you their emails.

We have a working MBean JB version 3.2.3.

Which version of JBoss are you all trying to implement MBean service on?
--
RK
On 7/21/05, David VINCENT <dvi...@sm...> 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
>=20
> Hi Joerg,
>=20
> It works very well with JBoss now. Steve and I already started working =
on
> adding JMX capabilities to QuickFix/J. We have a prototype working =
very
well
> with JBoss and MX4J by instrumenting Sessions. If you are interested, =
let
us
> know. As far as Messages are Serializable, you can also use them as
> parameters of your EJBs. We experimented that and it's very useful.
>=20
> What kind of integration do you want to do with JBoss ? I'm very
interested
> in exchanging ideas about it.
>=20
> Regards
>=20
> David
>=20
> -----Message d'origine-----
> De: qui...@li...
> [mailto:qui...@li...] De la part de
Joerg
> Thoennes
> Envoy=E9: jeudi 21 juillet 2005 08:11
> =C0: Steve Bate
> Cc: qui...@li...;
> qui...@li...
> Objet: Re: [Quickfix-developers] QuickFIX/J Beta 1 Available
>=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
> Hi Steve,
>=20
> > I am pleased to announce the first beta release of QuickFIX/J, a =
pure
> > Java port of the QuickFIX C++ FIX engine. The QuickFIX/J API is
> > identical to the QuickFIX JNI Java API. It should be possible to
> > simply redefine the Java classpath to start using QuickFIX/J if =
you've
> > been using the JNI version.
>=20
> Congratulations! Great job, well done. Thank you, Steve, Oren, Barry,
David
> and Laurent!
>=20
> Personally, I was waiting a long time for a pure Java port for easier =
J2EE
> integration,
> but could not offer the time to do it. Now we can proceed to integrate
> QuickFIX/J into JBoss.
>=20
> We have already started using QuickFIX/J for development (from CVS) =
and it
> works like a
> charm. (Otherwise, we are happy to use the bugtracker ;-)
>=20
> Eventually, we also will use it for production. But first there will =
be a
> longer testing
> period. I would love to hear Barry Kaplans experiences in QuickFIX/J's
usage
> for real trading.
>=20
> Looking forward to the first major release...
>=20
> Cheers, J=F6rg
>=20
> --
> Joerg Thoennes
>                                http://macd.com
> Tel.: +49 (0)241 44597-24      Macdonald Associates GmbH
> Fax : +49 (0)241 44597-10      Lothringer Str. 52, D-52070 Aachen
>=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_id=3D7477&alloc_id=3D16492&op=3Dclick
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>=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&opclick
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

Re: [Quickfix-users] Re: threading growth issue?

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

Alvin Wang wrote:
> It is Initiator. Only one session. Version is quickfix-1.9.4. OS is Windows Server 2003 
> SP1.
> 
> The reason we use JConsole to monitor QF is that we updated from Java 
> 1.5.0_02 to 1.5.0_04 and then the FIX engine crash once or twice every day 
> (sometimes when session is up and sometime session is down). I do not know 
> if the crash has anything to do with threading growth.  We did not have 
> the crash when we used Java 1.5.0_02, but I do not know what about 
> threading growth issue under 1.5.0_02.  I also am not sure if the crash is 
> related to java itself or to QF. 

Maybe this sections from the 1.10.0 release notes is relevant, since the # of threads 
climbs until StartTime:

> Initiator will no longer initiate socket connections outside of the session
> time.  Previously it would connect and immediately close connection during
> every retry interval.

Oren, perhaps you can give more details what you have changed here.

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-users] threading growth issue?

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

Alvin -

This sounds like it might be related to the between sessions socket
creation bug that was fixed in 10.0.0.

"Initiator will no longer initiate socket connections outside of the
session time.  Previously it would connect and immediately close
connection during every retry interval."

I don't know enough about the JNI implementation, but if the thread
spawned during the creation of the socket didn't get killed when the
socket was closed, it could cause the behavior you're describing.

You might want to try 1.10.2 and see if the problem remains.

- Brian Erst
Thynk Software, Inc.

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

> Hi,
> 
> I configure my QF(Java/JNI) engine something like:
> StartTime=08:00:00
> EndTime=23:55:00
> 
> I use JConsole (java 1.5.04) to monitor the QF engine's JVM. Before
> the 
> endtime, there were less than 20 threads running. After that, the #
> of 
> threads kept climbing progressively to about 2000 until StartTime.
> After 
> QF re-create the session, the # of thread stopped growing.
> 
> Can anyone explain to me what is going on here? It looks very
> disturbing.
> 
> 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-users] Re: [Quickfix-developers] QuickFIX/J Beta 1 Available

[VP M. IT A. E. T. <ass...@gm...>]

Hi David

There were a few others who did work and have posted msgs on the
list.

Later I will send you their emails.

We have a working MBean JB version 3.2.3.

Which version of JBoss are you all trying to implement MBean service on?
--
RK
On 7/21/05, David VINCENT <dvi...@sm...> wrote:
> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/i=
ndex.html
> QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> QuickFIX Support: http://www.quickfixengine.org/services.html
>=20
> Hi Joerg,
>=20
> It works very well with JBoss now. Steve and I already started working on
> adding JMX capabilities to QuickFix/J. We have a prototype working very w=
ell
> with JBoss and MX4J by instrumenting Sessions. If you are interested, let=
 us
> know. As far as Messages are Serializable, you can also use them as
> parameters of your EJBs. We experimented that and it's very useful.
>=20
> What kind of integration do you want to do with JBoss ? I'm very interest=
ed
> in exchanging ideas about it.
>=20
> Regards
>=20
> David
>=20
> -----Message d'origine-----
> De: qui...@li...
> [mailto:qui...@li...] De la part de Jo=
erg
> Thoennes
> Envoy=E9: jeudi 21 juillet 2005 08:11
> =C0: Steve Bate
> Cc: qui...@li...;
> qui...@li...
> Objet: Re: [Quickfix-developers] QuickFIX/J Beta 1 Available
>=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
> Hi Steve,
>=20
> > I am pleased to announce the first beta release of QuickFIX/J, a pure
> > Java port of the QuickFIX C++ FIX engine. The QuickFIX/J API is
> > identical to the QuickFIX JNI Java API. It should be possible to
> > simply redefine the Java classpath to start using QuickFIX/J if you've
> > been using the JNI version.
>=20
> Congratulations! Great job, well done. Thank you, Steve, Oren, Barry, Dav=
id
> and Laurent!
>=20
> Personally, I was waiting a long time for a pure Java port for easier J2E=
E
> integration,
> but could not offer the time to do it. Now we can proceed to integrate
> QuickFIX/J into JBoss.
>=20
> We have already started using QuickFIX/J for development (from CVS) and i=
t
> works like a
> charm. (Otherwise, we are happy to use the bugtracker ;-)
>=20
> Eventually, we also will use it for production. But first there will be a
> longer testing
> period. I would love to hear Barry Kaplans experiences in QuickFIX/J's us=
age
> for real trading.
>=20
> Looking forward to the first major release...
>=20
> Cheers, J=F6rg
>=20
> --
> Joerg Thoennes
>                                http://macd.com
> Tel.: +49 (0)241 44597-24      Macdonald Associates GmbH
> Fax : +49 (0)241 44597-10      Lothringer Str. 52, D-52070 Aachen
>=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_id=3D7477&alloc_id=3D16492&op=3Dclic=
k
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>=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&opclick
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

[Quickfix-users] Re: threading growth issue?

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

It is Initiator. Only one session. Version is quickfix-1.9.4. OS is Windows Server 2003 
SP1.

The reason we use JConsole to monitor QF is that we updated from Java 
1.5.0_02 to 1.5.0_04 and then the FIX engine crash once or twice every day 
(sometimes when session is up and sometime session is down). I do not know 
if the crash has anything to do with threading growth.  We did not have 
the crash when we used Java 1.5.0_02, but I do not know what about 
threading growth issue under 1.5.0_02.  I also am not sure if the crash is 
related to java itself or to QF. 

Thanks!






Oren Miller <or...@qu...>
07/21/2005 11:53 AM

 
        To:     Alvin Wang <AW...@FF...>
        cc:     qui...@li..., quickfix-users list 
<qui...@li...>
        bcc: 
        Subject:        Re: threading growth issue?


Please give more details on  your configuration. 
ThreadedSocketAcceptor?  Initiator?  Number of sessions... version of 
QF... operating system...

--oren

On Jul 21, 2005, at 2:39 PM, Alvin Wang wrote:

>
> Hi,
>
> I configure my QF(Java/JNI) engine something like:
> StartTime=08:00:00
> EndTime=23:55:00
>
> I use JConsole (java 1.5.04) to monitor the QF engine's JVM. Before 
> the endtime, there were less than 20 threads running. After that, 
> the # of threads kept climbing progressively to about 2000 until 
> StartTime. After QF re-create the session, the # of thread stopped 
> growing.
>
> Can anyone explain to me what is going on here? It looks very 
> disturbing.
>
> 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-users] Re: threading growth issue?

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

Please give more details on  your configuration.   
ThreadedSocketAcceptor?  Initiator?  Number of sessions... version of  
QF... operating system...

--oren

On Jul 21, 2005, at 2:39 PM, Alvin Wang wrote:

>
> Hi,
>
> I configure my QF(Java/JNI) engine something like:
> StartTime=08:00:00
> EndTime=23:55:00
>
> I use JConsole (java 1.5.04) to monitor the QF engine's JVM. Before  
> the endtime, there were less than 20 threads running. After that,  
> the # of threads kept climbing progressively to about 2000 until  
> StartTime. After QF re-create the session, the # of thread stopped  
> growing.
>
> Can anyone explain to me what is going on here? It looks very  
> disturbing.
>
> 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-users] threading growth issue?

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

Hi,

I configure my QF(Java/JNI) engine something like:
StartTime=08:00:00
EndTime=23:55:00

I use JConsole (java 1.5.04) to monitor the QF engine's JVM. Before the 
endtime, there were less than 20 threads running. After that, the # of 
threads kept climbing progressively to about 2000 until StartTime. After 
QF re-create the session, the # of thread stopped growing.

Can anyone explain to me what is going on here? It looks very disturbing.

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-users] QuickFIX/J Beta 1 Available

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

I see mention in his email about the Acceptor failing to respond to =20
events (which has since been fixed).  I do not see any mention of =20
core dumps on failed logons from Nick or anyone else.  I would be =20
interested to hear more details about this.

--oren

On Jul 21, 2005, at 4:47 AM, Joerg Thoennes wrote:

> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/=20
> html/index.html
> QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php?=20
> QuickFixFAQ
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Nick Evgeniev wrote:
>
>> It's a greate news! Hopefully it would not coredump on every =20
>> broken logon
>> request as jni version does!
>>
>
> If you do not add any native stuff... ;-)
>
> But seriously: Did you report these coredumps via the bugtracker? I =20=

> remember some mailings from you in the end of June.
>
> Cheers, J=F6rg
>
> --=20
> Joerg Thoennes
>                                http://macd.com
> Tel.: +49 (0)241 44597-24      Macdonald Associates GmbH
> Fax : +49 (0)241 44597-10      Lothringer Str. 52, D-52070 Aachen
>
>
> -------------------------------------------------------
> 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=3D7477&alloc_id=3D16492&op=3Dcli=
ck
> _______________________________________________
> Quickfix-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-users
>
>

Re: [Quickfix-users] QuickFIX/J Beta 1 Available

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

Nick Evgeniev wrote:
> It's a greate news! Hopefully it would not coredump on every broken logon
> request as jni version does!

If you do not add any native stuff... ;-)

But seriously: Did you report these coredumps via the bugtracker? I remember some mailings 
from you in the end of June.

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-users] QuickFIX/J Beta 1 Available

[Nick E. <ni...@de...>]

Hi,

It's a greate news! Hopefully it would not coredump on every broken logon
request as jni version does!

----- Original Message ----- 
From: "Steve Bate" <st...@qu...>
To: <qui...@li...>; 
<qui...@li...>; 
<qui...@li...>
Sent: Thursday, July 21, 2005 8:00 AM
Subject: [Quickfix-users] QuickFIX/J Beta 1 Available


> 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 am pleased to announce the first beta release of QuickFIX/J, a pure
> Java port of the QuickFIX C++ FIX engine. The QuickFIX/J API is
> identical to the QuickFIX JNI Java API. It should be possible to
> simply redefine the Java classpath to start using QuickFIX/J if you've
> been using the JNI version.
>
> The primary focus of this version was porting the C++ and Ruby code to
> Java. However, there are a few additional features.  For example...
>
> * QuickFIX/J messages are serializable
> * General JDBC log and store support
> * Jakarta Commons Logging support (JDK, Log4J)
> * Javadoc documentation
> * A few new configurations options
>
> We are also seeing better performance with QuickFIX/J compared to the
> JNI implementation. Depending on the test, we are seeing between 3-10x
> speed improvement.
>
> QuickFIX/J is passing the same acceptance tests as the C++
> implementation and is also passing numerous unit tests. The code is
> stable but we are expecting minor issues with compatibility, bugs, and
> so on once developers start using it. Please follow the guidelines
> recently suggested by Joerg Thoennes for reporting bugs and issues
> using the QuickFIX bug tracker. The message containing those
> guidelines is...
>
> http://sourceforge.net/mailarchive/message.php?msg_id=12260171
>
> Several people have provided valuable assistance to the QuickFIX/J
> effort. David Vincent and Laurent Danesi from Smart Trade Technologies
> have provided coding and testing support and have set up a Cruise
> Control continuous integration server for doing automated builds and
> test report generation. Barry Kaplan has been using the engine for
> real trading and has provided early feedback on bugs and other
> issues. These developers are also involved in some very interesting
> features for future versions of QuickFIX/J. We'll describe those in
> future messages. Oren Miller has provided project management
> assistance and has patiently answered our numerous questions about the
> C++ implementation.
>
> We are hoping that the Java QuickFIX users will help us improve the
> quality of the QuickFIX/J implementation by trying the software and
> reporting bugs or other issues. If you'd like to get involved as a
> developer, send me a note and let me know how you'd like to
> participate. I'm also interested in hearing from people who are
> experts on the FIX protocol or applications of FIX and who would be
> willing to consult with the development team when we have questions.
>
> The code is available as a binary or source package from the
> QuickFIX SourceForge file download area.
>
> http://sourceforge.net/project/showfiles.php?group_id=37535
>
> Steve Bate
>
>
>
>
> -------------------------------------------------------
> 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-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-users 

[Quickfix-users] RE: [Quickfix-developers] QuickFIX/J Beta 1 Available

[David V. <dvi...@sm...>]

Hi Joerg,

It works very well with JBoss now. Steve and I already started working =
on
adding JMX capabilities to QuickFix/J. We have a prototype working very =
well
with JBoss and MX4J by instrumenting Sessions. If you are interested, =
let us
know. As far as Messages are Serializable, you can also use them as
parameters of your EJBs. We experimented that and it's very useful.

What kind of integration do you want to do with JBoss ? I'm very =
interested
in exchanging ideas about it.

Regards

David

-----Message d'origine-----
De=A0: qui...@li...
[mailto:qui...@li...] De la part de =
Joerg
Thoennes
Envoy=E9=A0: jeudi 21 juillet 2005 08:11
=C0=A0: Steve Bate
Cc=A0: qui...@li...;
qui...@li...
Objet=A0: Re: [Quickfix-developers] QuickFIX/J Beta 1 Available

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 Steve,

> I am pleased to announce the first beta release of QuickFIX/J, a pure
> Java port of the QuickFIX C++ FIX engine. The QuickFIX/J API is
> identical to the QuickFIX JNI Java API. It should be possible to
> simply redefine the Java classpath to start using QuickFIX/J if you've
> been using the JNI version.

Congratulations! Great job, well done. Thank you, Steve, Oren, Barry, =
David
and Laurent!

Personally, I was waiting a long time for a pure Java port for easier =
J2EE
integration,=20
but could not offer the time to do it. Now we can proceed to integrate
QuickFIX/J into JBoss.

We have already started using QuickFIX/J for development (from CVS) and =
it
works like a=20
charm. (Otherwise, we are happy to use the bugtracker ;-)

Eventually, we also will use it for production. But first there will be =
a
longer testing=20
period. I would love to hear Barry Kaplans experiences in QuickFIX/J's =
usage
for real trading.

Looking forward to the first major release...

Cheers, J=F6rg

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


-------------------------------------------------------
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=3D7477&alloc_id=3D16492&op=3Dclick
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers

[Quickfix-users] Re: [Quickfix-developers] QuickFIX/J Beta 1 Available

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

Hi Steve,

> I am pleased to announce the first beta release of QuickFIX/J, a pure
> Java port of the QuickFIX C++ FIX engine. The QuickFIX/J API is
> identical to the QuickFIX JNI Java API. It should be possible to
> simply redefine the Java classpath to start using QuickFIX/J if you've
> been using the JNI version.

Thanks again for the great work, so my posting on the list.

> We are hoping that the Java QuickFIX users will help us improve the
> quality of the QuickFIX/J implementation by trying the software and
> reporting bugs or other issues. If you'd like to get involved as a
> developer, send me a note and let me know how you'd like to
> participate. I'm also interested in hearing from people who are
> experts on the FIX protocol or applications of FIX and who would be
> willing to consult with the development team when we have questions.

Of course I would like to contribute! Since we are started using it, we would like to 
access to Wiki and get commit access to the repository.

Please tell me how we can proceed.

If you have an ICQ number, it would be nice to have that. Mine is 340538235.
With Oren, I chat quite often. Seems to be more effective than e-mail.

Cheers, Jörg

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

[Quickfix-users] Re: [Quickfix-developers] QuickFIX/J Beta 1 Available

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

Hi Steve,

> I am pleased to announce the first beta release of QuickFIX/J, a pure
> Java port of the QuickFIX C++ FIX engine. The QuickFIX/J API is
> identical to the QuickFIX JNI Java API. It should be possible to
> simply redefine the Java classpath to start using QuickFIX/J if you've
> been using the JNI version.

Congratulations! Great job, well done. Thank you, Steve, Oren, Barry, David and Laurent!

Personally, I was waiting a long time for a pure Java port for easier J2EE integration, 
but could not offer the time to do it. Now we can proceed to integrate QuickFIX/J into JBoss.

We have already started using QuickFIX/J for development (from CVS) and it works like a 
charm. (Otherwise, we are happy to use the bugtracker ;-)

Eventually, we also will use it for production. But first there will be a longer testing 
period. I would love to hear Barry Kaplans experiences in QuickFIX/J's usage for real trading.

Looking forward to the first major release...

Cheers, Jörg

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

[Quickfix-users] QuickFIX/J Beta 1 Available

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

I am pleased to announce the first beta release of QuickFIX/J, a pure
Java port of the QuickFIX C++ FIX engine. The QuickFIX/J API is
identical to the QuickFIX JNI Java API. It should be possible to
simply redefine the Java classpath to start using QuickFIX/J if you've
been using the JNI version.

The primary focus of this version was porting the C++ and Ruby code to
Java. However, there are a few additional features.  For example...

* QuickFIX/J messages are serializable
* General JDBC log and store support
* Jakarta Commons Logging support (JDK, Log4J)
* Javadoc documentation
* A few new configurations options

We are also seeing better performance with QuickFIX/J compared to the
JNI implementation. Depending on the test, we are seeing between 3-10x
speed improvement.

QuickFIX/J is passing the same acceptance tests as the C++
implementation and is also passing numerous unit tests. The code is
stable but we are expecting minor issues with compatibility, bugs, and
so on once developers start using it. Please follow the guidelines
recently suggested by Joerg Thoennes for reporting bugs and issues
using the QuickFIX bug tracker. The message containing those
guidelines is...

http://sourceforge.net/mailarchive/message.php?msg_id=12260171

Several people have provided valuable assistance to the QuickFIX/J
effort. David Vincent and Laurent Danesi from Smart Trade Technologies
have provided coding and testing support and have set up a Cruise
Control continuous integration server for doing automated builds and
test report generation. Barry Kaplan has been using the engine for
real trading and has provided early feedback on bugs and other
issues. These developers are also involved in some very interesting
features for future versions of QuickFIX/J. We'll describe those in
future messages. Oren Miller has provided project management
assistance and has patiently answered our numerous questions about the
C++ implementation.

We are hoping that the Java QuickFIX users will help us improve the
quality of the QuickFIX/J implementation by trying the software and
reporting bugs or other issues. If you'd like to get involved as a
developer, send me a note and let me know how you'd like to
participate. I'm also interested in hearing from people who are
experts on the FIX protocol or applications of FIX and who would be
willing to consult with the development team when we have questions.

The code is available as a binary or source package from the 
QuickFIX SourceForge file download area.

http://sourceforge.net/project/showfiles.php?group_id=37535

Steve Bate

Re: [Quickfix-users] How to prevent sending NewOrderRequest in response to ResendRequest

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

Sumit -

After you've trapped (toApp/toAdmin) and cracked the message, you can
simply throw a FIX::DoNotSend exception for those messages you do not
wish to resend. This will prevent the message from being resent - QF
should send a gap-fill for those messages you've decide not to resend.

- Brian Erst
Thynk Software, Inc.

--- Sumit Kumar <sk_...@ya...> wrote:

> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX FAQ:
> http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> QuickFIX Support: http://www.quickfixengine.org/services.html
> 
> Hi,
> 
> I am using quickfix 1.10.2.
> 
> When my client receives a ResendRequest from the other
> connecting party the messages within the requested
> range are relayed back.
> 
> If the NewOrderRequests or OrderCancelReplace requests
> are relayed back to the other party (and are
> processed) it might result in a risky situation of
> duplicating the orders.
> 
> To prevent this from happening, I wanted to filter out
> these messages while responding to ResendRequest from
> the other party. 
> 
> I might be able to select (using toApp) and crack the
> NewOrderSingle (and OrderCancelReplace) messages and
> determine them to be duplicate messages, But how do I
> prevent them from being sent again?
> 
> Additionally, what should be the right course of
> action considering both the connecting parties. 
> 
> Thanks
> 
> Sumit Kumar
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
> 
> 
> -------------------------------------------------------
> 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-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-users
> 

Re: [Quickfix-users] Logon with ResetSeqNumFlag and BOX

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

I guess we will need to handle the situation where the counter-party =20
fails to put the reset flag in.  fromAdmin won't do the trick.  =20
Incoming messages are not designed to be modified.  (in the C++ API =20
they are declared const).

I suppose if the sequence number is what we are expecting, we don't =20
necessarily have to care that the ResetSeqNumFlag is present.  (they =20
are supposed to do this BTW, let them know).  I think it is probably =20
a pretty sage assumption that the sequence numbers were reset =20
regardless because: 1) They accepted the logon, so they were ok with =20
receiving a sequence number of 1, otherwise we would have been =20
disconnected. 2) We can see that they are sending us a sequence =20
number of 1, which is what we expect.

So I think implementing the functionality you suggest regarding =20
checking the sequence number and processing it as a reset if we have =20
a pending reset.

If anyone thinks this is a bad idea, or can think of a scenario this =20
might back-fire, please let me know.  I can think of a couple =20
scenarios that aren't too significant in my opinion.

--oren

On Jul 14, 2005, at 6:10 PM, Ark...@ub... wrote:

> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/=20
> html/index.html
> QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php?=20
> QuickFixFAQ
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Hello All!
>
> I am using QuickFix to connect to BOX (http://=20
> www.bostonoptions.com/). I am using version 1.10.2 of QuickFix, so =20
> I am able to request a session reset by setting ResetSeqNumFlag  in =20=

> my logon message (thank you for this feature!). However, I see an =20
> interesting snag. BOX responds with its own Logon message, but in =20
> the response, BOX does not set the ResetSeqNumFlag flag. QuickFix =20
> exepects the flag to be set, otherwise the logon response is =20
> treated as logon request:
>
>
>>>>>>>>>>>>>>>> Session.cpp:220
>>>>>>>>>>>>>>>>
>   if ( !m_state.initiate()
>        || (m_state.sentReset() && !m_state.receivedReset()) )
>   {
>     if( logon.isSetField(m_state.heartBtInt()) )
>       logon.getField( m_state.heartBtInt() );
>     m_state.onEvent( "Received logon request" );
>     generateLogon( logon );
>     m_state.onEvent( "Responding to logon request" );
>   }
> <<<<<<<<<<<<<<<
>
>
> So I get to send another logon, and then another. Since I only set =20
> ResetSeqNumFlag in the original Logon message, the session =20
> eventually settles down, after sending 3 logons and receiving 1 =20
> response.
>
> Would it be possible to either treat logon response with seq number =20=

> 1 as if it has ResetSeqNumFlag? Or may be let me add the flag in =20
> Application::fromAdmin (as it is now, Application::fromAdmin is =20
> called after the check for ResetSeqNumFlag is done.
>
>
> Sincerely,
>         Arkadiy Belousov.
>
>
>
>
>
>
> Visit our website at http://www.ubs.com
>
> This message contains confidential information and is intended only
> for the individual named.  If you are not the named addressee you
> should not disseminate, distribute or copy this e-mail.  Please
> notify the sender immediately by e-mail if you have received this
> e-mail by mistake and delete this e-mail from your system.
>
> E-mail transmission cannot be guaranteed to be secure or error-free
> as information could be intercepted, corrupted, lost, destroyed,
> arrive late or incomplete, or contain viruses.  The sender therefore
> does not accept liability for any errors or omissions in the contents
> of this message which arise as a result of e-mail transmission.  If
> verification is required please request a hard-copy version.  This
> message is provided for informational purposes and should not be
> construed as a solicitation or offer to buy or sell any securities or
> related financial instruments.
>
>
>
> -------------------------------------------------------
> 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=3Dclick
> _______________________________________________
> Quickfix-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-users
>
>

Re: [Quickfix-users] Cancel, Limit & Stop

[Alberto B. <bellido@3.14financial.com>]

Thank you all for your answers ;)

Alberto Bellido

[Quickfix-users] ThreadedSocketAcceptor network problems

[Alberto B. <bellido@3.14financial.com>]

Hi

I'm suffering a strange behaviour in a ThreadedSocketAcceptor server. 

I connect some clients to it so they can receive data. Everything goes
ok. But if I pull the network cable from a client and the server tries
to send the client some data, there's a big problem. The server keeps
trying to send the data to the client (captured with Ethereal) for 15
minutes (sending the data + heartbeats) and answers no one else. After
those 15 minutes, the server returns to its normal behaviour and all the
clients can communicate with it.

It seems there's one thread locked and there's nothing managing that
situation.

Any ideas?

Thank you in advance

   Alberto

PS: I've searched quickfix mailing lists, documentation & google, but
nothing seems to solve my problem.

[Quickfix-users] Logon with ResetSeqNumFlag and BOX

[<Ark...@ub...>]

Hello All!

I am using QuickFix to connect to BOX (http://www.bostonoptions.com/). I =
am using version 1.10.2 of QuickFix, so I am able to request a session =
reset by setting ResetSeqNumFlag  in my logon message (thank you for =
this feature!). However, I see an interesting snag. BOX responds with =
its own Logon message, but in the response, BOX does not set the =
ResetSeqNumFlag flag. QuickFix exepects the flag to be set, otherwise =
the logon response is treated as logon request:

>>>>>>>>>>>>>>> Session.cpp:220
  if ( !m_state.initiate()=20
       || (m_state.sentReset() && !m_state.receivedReset()) )
  {
    if( logon.isSetField(m_state.heartBtInt()) )
      logon.getField( m_state.heartBtInt() );
    m_state.onEvent( "Received logon request" );
    generateLogon( logon );
    m_state.onEvent( "Responding to logon request" );
  }
<<<<<<<<<<<<<<<


So I get to send another logon, and then another. Since I only set =
ResetSeqNumFlag in the original Logon message, the session eventually =
settles down, after sending 3 logons and receiving 1 response.

Would it be possible to either treat logon response with seq number 1 as =
if it has ResetSeqNumFlag? Or may be let me add the flag in =
Application::fromAdmin (as it is now, Application::fromAdmin is called =
after the check for ResetSeqNumFlag is done.


Sincerely,
		Arkadiy Belousov.






Visit our website at http://www.ubs.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.

[Quickfix-users] How to prevent sending NewOrderRequest in response to ResendRequest

[Sumit K. <sk_...@ya...>]

Hi,

I am using quickfix 1.10.2.

When my client receives a ResendRequest from the other
connecting party the messages within the requested
range are relayed back.

If the NewOrderRequests or OrderCancelReplace requests
are relayed back to the other party (and are
processed) it might result in a risky situation of
duplicating the orders.

To prevent this from happening, I wanted to filter out
these messages while responding to ResendRequest from
the other party. 

I might be able to select (using toApp) and crack the
NewOrderSingle (and OrderCancelReplace) messages and
determine them to be duplicate messages, But how do I
prevent them from being sent again?

Additionally, what should be the right course of
action considering both the connecting parties. 

Thanks

Sumit Kumar


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com