quickfix-developers — QuickFIX developers forum

Re: [Quickfix-developers] Logging messages conditionally

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

On 15 May 2006 17:45:19 +0200, sta...@mu...
> I'd like to _not_ log certain messages to the messages_log table.
> Specifically, market data information is not important enough to
> warrant the required storage space, and I would like not to store sent
> messages in the log.
>
> Is there an easy way to do this?

You could derive your own Log class from whichever Log you're
currently using and have it do nothing when it sees the message types
you want to ignore in the onIncoming/onOutgoing methods.  For more
interesting messages, call the base class method.

You'll need to do a string search (e.g. for "\00135=3D<X>\001") since
the Logs are passed strings, not Message objects.

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

[Quickfix-developers] Logging messages conditionally

[<sta...@mu...>]

I'd like to _not_ log certain messages to the messages_log table.
Specifically, market data information is not important enough to
warrant the required storage space, and I would like not to store sent
messages in the log.

Is there an easy way to do this?

Staffan

Re: [Quickfix-developers] Minor glitch in build.xml for quickfixj

[Staffan U. <sta...@mu...>]

From: Staffan Ulfberg <st...@ul...>
Subject: Re: [Quickfix-developers] Minor glitch in build.xml for quickfixj
To: "Steve Bate" <sb...@sm...>
Cc: <qui...@li...>
Date: 15 May 2006 15:47:26 +0200

"Steve Bate" <sb...@sm...> writes:

> Thanks Staffan. This has already been changed on the CVS HEAD. 
> The MINA-related packages have also been added and Netty has been
> removed.

So, where's the CVS repository really?  I'm using a checkout from
:pserver:ano...@cv...:/cvsroot/quickfix, updated
recently.

Someone wrote something about updates to the repository being flaky.
I've also read about moving to SVN.  How would I currently obtain the
latest version before submittning patches?

Staffan

[Quickfix-developers] CVS back online

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

The developer and public repositories are both back online.  New 
instructions on how to access the quickfix CVS servers are on our developers 
page: http://www.quickfixengine.org/developers.html

Re: [Quickfix-developers] Minor glitch in build.xml for quickfixj

[Staffan U. <st...@ul...>]

"Steve Bate" <sb...@sm...> writes:

> Thanks Staffan. This has already been changed on the CVS HEAD. 
> The MINA-related packages have also been added and Netty has been
> removed.

So, where's the CVS repository really?  I'm using a checkout from
:pserver:ano...@cv...:/cvsroot/quickfix, updated
recently.

Someone wrote something about updates to the repository being flaky.
I've also read about moving to SVN.  How would I currently obtain the
latest version before submittning patches?

Staffan

[Quickfix-developers] A small request

[Graham M. <gra...@gm...>]

So I'm going to try to say this in a way that doesn't start a
Ruby/Java holy war, but...  is there any interest in a Ruby API for
quickfix?  It seems that it would be relatively straightforward to
modify the existing Python SWIG specification to generate an interface
for Ruby.  I may be totally wrong, because I've never built a SWIG
interface before, but I just thought I'd suggest it, because we were
going to start playing with RoR for a project soon...

graham

RE: [Quickfix-developers] ThreadedSocketInitiator vs SocketInitiator

[Sean K. <sea...@pi...>]

May I suggest that there also be a thread pool option?  If an acceptor =
has hundreds of sessions configured, it won't be a good idea to spawn a =
thread per session...

--Sean

-----Original Message-----
From: qui...@li...
[mailto:qui...@li...]On Behalf Of
Oren Miller
Sent: Wednesday, May 10, 2006 12:56 PM
To: Brian Erst; Caleb Epstein; Nick Volpe
Cc: quickfix-developers
Subject: Re: [Quickfix-developers] ThreadedSocketInitiator vs
SocketInitiator


QuickFIX Documentation: =
http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX Support: http://www.quickfixengine.org/services.html

There was, however it was overrun by WikiSpam and I never got around to=20
researching solutions to the problem.

--oren

> p.s. Speaking of confusion, is there a QuickFIX wiki? While the =
existing=20
> documentation is sufficient for getting started, in order to really=20
> understand a lot of QF you have to read the mailing list archives. If =
we=20
> had a wiki, I'd be tempted to transfer at least some of the mailing =
list=20
> knowledge to the wiki, if only from an ongoing basis.



-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, =
security?
Get stuff done quickly with pre-integrated technology to make your job =
easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache =
Geronimo
http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D=
121642
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers

RE: [Quickfix-developers] Non-standard repeating group in TradingSessionStatus message

[Francis G. <fr...@at...>]

That works quite well.

Thank you,

Francis

-----Original Message-----
From: Oren Miller [mailto:or...@qu...] 
Sent: Thursday, May 11, 2006 18:53
To: Francis Gingras; qui...@li...
Subject: Re: [Quickfix-developers] Non-standard repeating group in
TradingSessionStatus message

You need to pass a couple of field numbers to the constructor.  The first is
the group count field, 146 in this case.  The second is the first field of
the repeating group, which is also used as the group delimiter, or 55 in
this case.  So...

Group group = new Group();

becomes

Group group = new Group( 146, 55 )

--oren

Re: [Quickfix-developers] Non-standard repeating group in TradingSessionStatus message

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

You need to pass a couple of field numbers to the constructor.  The first is 
the group count field, 146 in this case.  The second is the first field of 
the repeating group, which is also used as the group delimiter, or 55 in 
this case.  So...

Group group = new Group();

becomes

Group group = new Group( 146, 55 )

--oren

----- Original Message ----- 
From: "Francis Gingras" <fr...@at...>
To: <qui...@li...>
Sent: Thursday, May 11, 2006 1:12 PM
Subject: [Quickfix-developers] Non-standard repeating group in 
TradingSessionStatus message


> QuickFIX Documentation: 
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Hello all,
>
> I've been trying to parse a 4.4 TradingSessionStatus message with 
> repeating
> groups which are instrument blocks.
>
> 8=FIX.4.4
9=2464
35=h
49=target
56=Demo1
34=462
52=20060511-17:59:13
335=2
3
> 36=clearing
625=U100D1
339=2
325=N
340=2
58=Market is closed.  Any trading
> functionality is not
> available.
146=22
55=USD/CHF
15=USD
561=1
9003=10.45
9004=-10.95
9006=0.01
9
> 000=4
9001=4
9002=0.0001
9005=4
55=NZD/JPY
15=NZD
561=1
9003=12.25
9004=-13.
> 25
9006=0.01
9000=19
9001=2
9002=0.01
9005=19
55=CAD/JPY
15=CAD
561=1
9003=9
> .65
9004=-10.15
9006=0.01
9000=18
9001=2
9002=0.01
9005=18
55=EUR/CAD
15=EUR
>
> I work with the latest QF sources and .NET 2.
>
> int groups = message.getInt(new NoRelatedSym().getField());
> for (uint i = 1; i < groups; i++)
> {
>  Group group = new Group();
>  message.getGroup(i, group);
>  //This doesn't work because Group needs a parameter (what should it be?).
> How do I get the group?
> }
>
> Thanks,
>
> Francis
>
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job 
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
> 

[Quickfix-developers] Non-standard repeating group in TradingSessionStatus message

[Francis G. <fr...@at...>]

Hello all,
 
I've been trying to parse a 4.4 TradingSessionStatus message with repeating
groups which are instrument blocks.

8=FIX.4.4
9=2464
35=h
49=target
56=Demo1
34=462
52=20060511-17:59:13
335=2
3
36=clearing
625=U100D1
339=2
325=N
340=2
58=Market is closed.  Any trading
functionality is not
available.
146=22
55=USD/CHF
15=USD
561=1
9003=10.45
9004=-10.95
9006=0.01
9
000=4
9001=4
9002=0.0001
9005=4
55=NZD/JPY
15=NZD
561=1
9003=12.25
9004=-13.
25
9006=0.01
9000=19
9001=2
9002=0.01
9005=19
55=CAD/JPY
15=CAD
561=1
9003=9
.65
9004=-10.15
9006=0.01
9000=18
9001=2
9002=0.01
9005=18
55=EUR/CAD
15=EUR

I work with the latest QF sources and .NET 2.  

int groups = message.getInt(new NoRelatedSym().getField());
for (uint i = 1; i < groups; i++)
{
  Group group = new Group();
  message.getGroup(i, group);
  //This doesn't work because Group needs a parameter (what should it be?).
How do I get the group?
}

Thanks,

Francis

[Quickfix-developers] download

[Miguel P. <mpe...@ho...>]

<html><div style='background-color:'><P>Hi I tried to download the quickfix/J beta and when the progress window shows 99% complete, the download&nbsp;frezee, and never end, I need to finish the donwload, you can send the files to my mail please?&nbsp;or what can I do to download the aplication?</P>
<P>regads</P>
<P>miguel peralta</P>
<P>&nbsp;</P>
<P>And I thought that my president was stupid</P></div><br clear=all><hr>Acepta el reto MSN Premium: incluye Antivirus y Firewall de McAffee. <a href="http://g.msn.com/8HMAESES/2731??PS=47575" target="_top">Descárgalo y pruébalo 2 meses gratis.</a> </html>

[Quickfix-developers] Is quickfix.Session.sendToTarget() thread safe?

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

Hi,

I have created a FIX server using the Java support in QuickFIX
v1.11.1.

Twice while testing I've seen this emitted (to stderr presumably):

terminate called after throwing an instance of 'std::length_error'
   what():  basic_string::_S_create
/home/bboerner/bin/my_fix_server: line 32: 12183 Aborted  java -cp  
<blah, blah, blah>


I'm thinking that this may be an uncaught exception in the C++ code.

It prompts me to ask the question:

Are calls to quickfix.Session.sendToTarget(msg, session_id) thread
safe?

I'm assuming so since I see 'Locker locker( s_mutex )' in say
Session::lookupSession() but thought I'd verify instead of simply
assuming...

Regards,
Brendan

Re: [Quickfix-developers] ThreadedSocketInitiator vs SocketInitiator

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

Resending this as it bounced yesterday.  Sorry if you see a dupe.
GMail has been giving me fits lately.

On 5/10/06, Oren Miller <or...@qu...> wrote:
> Yeah, I'm reading that in unix it is typical to do a fork and have each
> process treat it as unidirectional to avoid deadlocks.  So we would have =
to

I think using non-blocking I/O and select is much more common.

I believe I submitted a patch about 18 months ago that made the
Socket* classes use non-blocking sockets and did I/O multiplexing with
select to handle both read- and write-readiness, but I never pushed
hard enough to get this into QF.

> have a thread for sending and a thread for receiving.  This is actually
> something we had talked about in the past to prevent deadlocks when sendi=
ng
> from callbacks.  Essentially creating a sending queue.  I am wondering
> however if we really do need the SocketInitiator/Acceptor or if it should=
 be
> deprecated in favor of the threaded versions.  I think the precense of bo=
th
> of them has been one of the more confusing aspects of QuickFIX and not su=
re
> it really is advantageous to have both at this point.  Any thoughts on th=
is?

I think ditching the non-threaded Socket* classes would be a win,
because it would reduce the overall surface area of the library and
simplify the new-user experience by eliminating the descision about
which type of Acceptor/Connector to use.

Some folks are very anti-thread, though, so they may want to have a
non-MT choice, but the implementation should be improved if it is
going to be kept around.

As far as design questions go, I think it might make sense to come up
with an something that exists somewhere between the current
non-threaded Socket* classes and the thread-per-connection
ThreadedSocket* classes.  I am of the mind that a thread per
connection is almost always a waste of resources, and that I/O
multiplexing with select/poll/WFMO and a thread pool might be a better
option.

As an aside, it would also be nice if the user didn't need to choose
specific Acceptor/Connector implementations in their application at
all, but if there was some central "Dispatcher" that handled both
types of functions.

--
Caleb Epstein
caleb dot epstein at gmail dot com

RE: [Quickfix-developers] postgres store issue

[Steve B. <sb...@sm...>]

Just FYI for QFJ users, the JdbcStore in QFJ shouldn't have this problem
because it uses prepared statements that automatically quote special
characters in query fields.
=20
Steve


________________________________

	From: qui...@li...
[mailto:qui...@li...] On Behalf Of
Sean Kirkpatrick
	Sent: Wednesday, May 10, 2006 7:06 PM
	To: qui...@li...
	Subject: [Quickfix-developers] postgres store issue
=09
=09

	Hello All,=20

	We've encountered an issue with the postgres message store / log
involving messages that have tags populated with text containing a " '
".  Because this is the default text delimiter in postgres, it breaks
the insert.  I am currently patching my version of the library, but this
should probably be fixed for a future release of QuickFix.  It may also
be a problem in the other DB stores...

	Thanks!=20

	Sean Kirkpatrick=20

RE: [Quickfix-developers] ThreadedSocketInitiator vs SocketInitiator

[Steve B. <sb...@sm...>]

=20
I vote for removing it or making it a fa=E7ade. In QFJ, the primary
difference between the two in a single session scenario are the
behavior of the block and poll methods. QFJ uses asynchronous
IO (NIO) with low level read/write queues so I don't think it
will have this particular problem. However, with queues there
is another issue with managing their size under heavy load with
a fast producer and slow consumer.

Steve

> -----Original Message-----
> From: qui...@li...=20
> [mailto:qui...@li...] On=20
> Behalf Of Oren Miller
> Sent: Wednesday, May 10, 2006 6:01 PM
> To: Caleb Epstein; Nick Volpe
> Cc: quickfix-developers
> Subject: Re: [Quickfix-developers] ThreadedSocketInitiator vs=20
> SocketInitiator
>=20
> QuickFIX Documentation:=20
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>=20
> Yeah, I'm reading that in unix it is typical to do a fork and=20
> have each=20
> process treat it as unidirectional to avoid deadlocks.  So we=20
> would have to=20
> have a thread for sending and a thread for receiving.  This=20
> is actually=20
> something we had talked about in the past to prevent=20
> deadlocks when sending=20
> from callbacks.  Essentially creating a sending queue.  I am=20
> wondering=20
> however if we really do need the SocketInitiator/Acceptor or=20
> if it should be=20
> deprecated in favor of the threaded versions.  I think the=20
> precense of both=20
> of them has been one of the more confusing aspects of=20
> QuickFIX and not sure=20
> it really is advantageous to have both at this point.  Any=20
> thoughts on this?
>=20
> --oren
>=20
> ----- Original Message -----=20
> From: "Caleb Epstein" <cal...@gm...>
> To: "Nick Volpe" <ni...@ad...>
> Cc: "quickfix-developers" <qui...@li...>
> Sent: Tuesday, May 09, 2006 11:08 AM
> Subject: Re: [Quickfix-developers] ThreadedSocketInitiator vs=20
> SocketInitiator
>=20
>=20
> QuickFIX Documentation:=20
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>=20
> I don't think this made it through the first time.
>=20
> On 5/9/06, Nick Volpe <ni...@ad...> wrote:
> >
> > Can anyone tell me pros/cons of using a=20
> ThreadedSocketInitiator versus a
> > Socket Initiator?  I c an't seem to find much in the=20
> documentation or the
> > mailing list archives.  Any help would be greatly appreciated.
>=20
> The non-threaded SocketInitiator can actually get into a deadlock
> situation whereby your application will block forever.  I would
> recommend against anyone ever using it.
>=20
> This deadlock will happen if your application fills up a socket's
> sending buffer while the other side is doing the same (e.g. two
> non-threaded QuickFIX apps generating heavy traffic).  Neither side
> will end up reading from its side of the socket, being blocked in a
> send() call, and both sides will deadlock.
>=20
> --
> Caleb Epstein
> caleb dot epstein at gmail dot com
>=20
>=20
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web=20
> services, security?
> Get stuff done quickly with pre-integrated technology to make=20
> your job=20
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on=20
> Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=120709&bid&3057&dat=121642
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>=20
>=20
>=20
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web=20
> services, security?
> Get stuff done quickly with pre-integrated technology to make=20
> your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on=20
> Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&
> dat=3D121642
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>=20

RE: [Quickfix-developers] Minor glitch in build.xml for quickfixj

[Steve B. <sb...@sm...>]

Thanks Staffan. This has already been changed on the CVS HEAD.=20
The MINA-related packages have also been added and Netty has been
removed.

Steve

> -----Original Message-----
> From: qui...@li...=20
> [mailto:qui...@li...] On=20
> Behalf Of Staffan Ulfberg
> Sent: Wednesday, May 10, 2006 5:35 PM
> To: qui...@li...
> Subject: [Quickfix-developers] Minor glitch in build.xml for quickfixj
>=20
> QuickFIX Documentation:=20
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>=20
> Patch follows.
>=20
> Staffan
>=20
>=20
> Index: build.xml
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> RCS file: /cvsroot/quickfix/quickfixj/build.xml,v
> retrieving revision 1.31
> diff -u -r1.31 build.xml
> --- build.xml   14 Feb 2006 21:26:07 -0000      1.31
> +++ build.xml   10 May 2006 15:33:14 -0000
> @@ -343,7 +343,7 @@
>                         <package name=3D"quickfix.netty" />
>                         <package name=3D"quickfix.field.converter" />
>                         <package name=3D"quickfix.codegen" />
> -                       <package name=3D"quickfix.fields" />
> +                       <package name=3D"quickfix.field" />
>                         <package name=3D"quickfix.fix*" />
>                 </javadoc>
>         </target>
>=20
>=20
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web=20
> services, security?
> Get stuff done quickly with pre-integrated technology to make=20
> your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on=20
> Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&
dat=3D121642
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>=20

Re: [Quickfix-developers] isCorrectCompID

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

Ajay -

Absolutely true. The backup channel only contains administrative messages and does not do sequencing at all (all messages to and from CME must have MsgSequenceNum=0) unless and until failover occurs and it becomes the primary channel. Then, you suddenly have to switch to the primary's sequence number. The CME will send a heartbeat to the backup that contains the sequence number that would have been sent on the primary channel (switching to the "P" version of the TargetCompID at the same time), and you must respond with the sequence number that the primary should have used next, also modifying the SenderCompID to the "P" version (from the "B" version).

Needless to say, it's not a fun task to manage...

- Brian Erst
Thynk Software, Inc.

----- Original Message ----
From: Ajay Kamdar <Aja...@tr...>
To: qui...@li...
Sent: Wednesday, May 10, 2006 1:13:21 PM
Subject: RE: [Quickfix-developers] isCorrectCompID

QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX Support: http://www.quickfixengine.org/services.html

Brian, I also faintly recall hearing second/third-hand that CME uses 0
as a sequence number for all messages on a backup FIX session up until
it becomes a primary. Is there any truth to that?

- Ajay

-----Original Message-----
From: Brian Erst [mailto:azz...@ya...] 
Sent: Wednesday, May 10, 2006 1:56 PM
To: Oren Miller; Jain, Anil; rho;
qui...@li...
Subject: Re: [Quickfix-developers] isCorrectCompID


QuickFIX Documentation:
http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX Support: http://www.quickfixengine.org/services.html

Oren -

Just to make you aware, CME really does violence to the whole
SenderCompID tag. When they created their new FIX gateway a few years
back, they removed just about all the routing intelligence that had been
built into the old one. Due to this fact, they ended up needing a field
that would allow both the failover routing (that whole "U" versus "P"
thing) as well as multi-clearing firm support (for instance, one of my
clients clears under 5-6 different clearing firm numbers due to a number
of acquisitions over the years). 

---------------------------------------------------------------------------

The information in this email is confidential and may be legally privileged.
It is intended solely for the addressee. Access to this email by anyone else
is unauthorized. If you are not the intended recipient, any disclosure, copying,
distribution or any action taken or omitted to be taken in reliance on it, is
prohibited and may be unlawful.

TradeWeb reserves the right to monitor and review the content of all messages sent
to or from this e-mail address. Messages sent to or from this e-mail address may
be stored on the TradeWeb e-mail system.



-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0709&bid&3057&dat1642
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers

RE: [Quickfix-developers] isCorrectCompID

[Jain, A. <Ani...@rb...>]

Oren, Brian
I agree with your observations. Thank you very much for sharing it.

Prima facie, I have not much justification in thinking about any QuickFIX c=
hange on this, Oren's suggestion is reasonably trying to accommodate CME FI=
X violations, and at the same time letting users use QuickFIX for CME.

As for the pattern matching, I was thinking more in terms of virtualising t=
his validation interface to user - for those who need it (the default is fi=
ne) - rather than allowing skipping through configuration. However, it is t=
rue that, once we skip validation via configuration, we then have the oppor=
tunity to validate in toAdmin/fromAdmin.=20

Thanks.

Anil Jain

-----Original Message-----
From: Brian Erst [mailto:azz...@ya...]
Sent: Wednesday, May 10, 2006 1:56 PM
To: Oren Miller; Jain, Anil; rho;
qui...@li...
Subject: Re: [Quickfix-developers] isCorrectCompID


Oren -

Just to make you aware, CME really does violence to the whole SenderCompID =
tag. When they created their new FIX gateway a few years back, they removed=
 just about all the routing intelligence that had been built into the old o=
ne. Due to this fact, they ended up needing a field that would allow both t=
he failover routing (that whole "U" versus "P" thing) as well as multi-clea=
ring firm support (for instance, one of my clients clears under 5-6 differe=
nt clearing firm numbers due to a number of acquisitions over the years).=20

Rather than putting that into a user defined field as they should have done=
 (or better still, Sender/TargetSubID), they used SenderCompID to handle it=
. You have a "master" session that you login with, but after that, the Send=
erCompID is split into three parts: a session identifier (3 chars), a clear=
ing firm number (3 numbers) and a failover indicator ("U", "P" or "N"). As =
long as your session id (first 3 chars) doesn't change and your firm number=
 (second 3 chars) is registered, you can modify things to your hearts conte=
nt.=20

It's the only way for big firms to enter orders using a single login. While=
 it ridiculously breaks FIX semantics for no good reason, it's far preferab=
le to other exchanges (Liffe/CBOT, I'm looking at you) that require separat=
e logins for each clearing firm number.

We run our own custom-developed FIX engine just for CME because it's such a=
n odd duck, FIX-wise. I like to think of it as "FIX inspired", rather than =
true FIX.

- Brian Erst
Thynk Software, Inc.

----- Original Message ----
From: Oren Miller <or...@qu...>
To: "Jain, Anil" <Ani...@rb...>; rho <tia...@ya...>; quick=
fix...@li...
Sent: Wednesday, May 10, 2006 12:32:58 PM
Subject: Re: [Quickfix-developers] isCorrectCompID

QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/ind=
ex.html
QuickFIX Support: http://www.quickfixengine.org/services.html

Well, the CME made the choice to break FIX compatibility by sending multipl=
e=20
comp ids on a single session.  Adding pattern matching or regex comparisons=20
to compids adds a lot of complexity with no real tangible benefit.  The sam=
e=20
goes for systems that choose to send some fields with no data.  Our solutio=
n=20
is going to be to turn turn off that validation for all fields in those=20
cases.  We don't intend on writing a validation system that will do that=20
validation for some fields and not for others.  The added effort and=20
complexity is just not worth it.

These are basic rules of the fix protocol.  By breaking this rule, the CME=20
is essentially saying that this rule does not apply.  Turning off the=20
validation is the simplest and most universal solution to the problem.  If=20
the CME has a habit of sending you messages from other sessions, then there=20
is a bigger problem they need to address.

--oren

----- Original Message -----=20
From: "Jain, Anil" <Ani...@rb...>
To: "Oren Miller" <or...@qu...>; "rho" <tia...@ya...>=
;=20
<qui...@li...>
Sent: Wednesday, May 10, 2006 12:18 PM
Subject: RE: [Quickfix-developers] isCorrectCompID


I do not understand your suggestion to make it configurable.
The validation, if it is needed, must be there, now that a pattern needs to=20
be validated, rather than a static data.
But, then neither have I used CME fault tolerance, nor I have sufficient QF=20
experience to encounter a failed validation in general.

Anil Jain

-----Original Message-----
From: qui...@li...
[mailto:qui...@li...]On Behalf Of
Oren Miller
Sent: Wednesday, May 10, 2006 1:02 PM
To: rho; qui...@li...
Subject: Re: [Quickfix-developers] isCorrectCompID


QuickFIX Documentation:=20
http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX Support: http://www.quickfixengine.org/services.html

Yeah, this is just a quick workaround.  In the end we will probably need to
add another validation config setting such as ValidateSenderCompID.

--oren

----- Original Message -----=20
From: "rho" <tia...@ya...>
To: <qui...@li...>
Sent: Wednesday, May 10, 2006 11:53 AM
Subject: Re: [Quickfix-developers] isCorrectCompID


> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
>
> The easy way to fix it is to modify the function one way or another. But
> that
> would mean a change of the quickfix library. I tried not to change the
> quickfix library.
>
> --
_______________________________________________________________________

This E-Mail (including any attachments) may contain privileged or confident=
ial information.  It is intended only for the addressee(s) indicated above.
The sender does not waive any of its rights, privileges or other protection=
s respecting this information. =20
Any distribution, copying or other use of this E-Mail or the information it=
 contains, by other than an intended recipient, is not sanctioned and is pr=
ohibited.
If you received this E-Mail in error, please delete it and advise the sende=
r (by return E-Mail or otherwise) immediately.

This E-Mail (including any attachments) has been scanned for viruses.=20
It is believed to be free of any virus or other defect that might affect an=
y computer system into which it is received and opened.=20
However, it is the responsibility of the recipient to ensure that it is vir=
us free.=20
The sender accepts no responsibility for any loss or damage arising in any =
way from its use.

E-Mail received by or sent from RBC Capital Markets is subject to review by=
 Supervisory personnel.=20
Such communications are retained and may be produced to regulatory authorit=
ies or others with legal rights to the information.

[Quickfix-developers] Error LNK2005 with comsuppd.lib

[Angel P. <ap...@es...>]

Hello

=20

            I'm working with VS.NET 2003 and C++, the version of =
quickfix is
1.11.1 and my platform is WXP.

            I have a problem when I'm linking quickfix with my program. =
I
get the following fatal error:

=20

comsuppd.lib(comutil.obj) : error LNK2005: "class _variant_t vtMissing"
(?vtMissing@@3V_variant_t@@A) already defined in =
comsuppwd.lib(comutil.obj)

=20

            In my code I have an #import to my COMponent that doesn't =
use
UNICODE, I never use UNICODE.=20

When I delete the import with my COMponent I had no problem. This =
COMponent
is being used in other projects in my company.

            Why my code use comsuppd.lib and comsuppwd.lib if I don't =
use
UNICODE?

=20

Thanks,           =20

=20

Angel Pinto L=F3pez




=20

RE: [Quickfix-developers] isCorrectCompID

[Ajay K. <Aja...@tr...>]

Brian, I also faintly recall hearing second/third-hand that CME uses 0
as a sequence number for all messages on a backup FIX session up until
it becomes a primary. Is there any truth to that?

- Ajay

-----Original Message-----
From: Brian Erst [mailto:azz...@ya...]=20
Sent: Wednesday, May 10, 2006 1:56 PM
To: Oren Miller; Jain, Anil; rho;
qui...@li...
Subject: Re: [Quickfix-developers] isCorrectCompID


QuickFIX Documentation:
http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX Support: http://www.quickfixengine.org/services.html

Oren -

Just to make you aware, CME really does violence to the whole
SenderCompID tag. When they created their new FIX gateway a few years
back, they removed just about all the routing intelligence that had been
built into the old one. Due to this fact, they ended up needing a field
that would allow both the failover routing (that whole "U" versus "P"
thing) as well as multi-clearing firm support (for instance, one of my
clients clears under 5-6 different clearing firm numbers due to a number
of acquisitions over the years).=20

-------------------------------------------------------------------------=
--

The information in this email is confidential and may be legally =
privileged.
It is intended solely for the addressee. Access to this email by anyone =
else
is unauthorized. If you are not the intended recipient, any disclosure, =
copying,
distribution or any action taken or omitted to be taken in reliance on =
it, is
prohibited and may be unlawful.

TradeWeb reserves the right to monitor and review the content of all =
messages sent
to or from this e-mail address. Messages sent to or from this e-mail =
address may
be stored on the TradeWeb e-mail system.

Re: [Quickfix-developers] isCorrectCompID

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

Oren -

Just to make you aware, CME really does violence to the whole SenderCompID tag. When they created their new FIX gateway a few years back, they removed just about all the routing intelligence that had been built into the old one. Due to this fact, they ended up needing a field that would allow both the failover routing (that whole "U" versus "P" thing) as well as multi-clearing firm support (for instance, one of my clients clears under 5-6 different clearing firm numbers due to a number of acquisitions over the years). 

Rather than putting that into a user defined field as they should have done (or better still, Sender/TargetSubID), they used SenderCompID to handle it. You have a "master" session that you login with, but after that, the SenderCompID is split into three parts: a session identifier (3 chars), a clearing firm number (3 numbers) and a failover indicator ("U", "P" or "N"). As long as your session id (first 3 chars) doesn't change and your firm number (second 3 chars) is registered, you can modify things to your hearts content. 

It's the only way for big firms to enter orders using a single login. While it ridiculously breaks FIX semantics for no good reason, it's far preferable to other exchanges (Liffe/CBOT, I'm looking at you) that require separate logins for each clearing firm number.

We run our own custom-developed FIX engine just for CME because it's such an odd duck, FIX-wise. I like to think of it as "FIX inspired", rather than true FIX.

- Brian Erst
Thynk Software, Inc.

----- Original Message ----
From: Oren Miller <or...@qu...>
To: "Jain, Anil" <Ani...@rb...>; rho <tia...@ya...>; qui...@li...
Sent: Wednesday, May 10, 2006 12:32:58 PM
Subject: Re: [Quickfix-developers] isCorrectCompID

QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX Support: http://www.quickfixengine.org/services.html

Well, the CME made the choice to break FIX compatibility by sending multiple 
comp ids on a single session.  Adding pattern matching or regex comparisons 
to compids adds a lot of complexity with no real tangible benefit.  The same 
goes for systems that choose to send some fields with no data.  Our solution 
is going to be to turn turn off that validation for all fields in those 
cases.  We don't intend on writing a validation system that will do that 
validation for some fields and not for others.  The added effort and 
complexity is just not worth it.

These are basic rules of the fix protocol.  By breaking this rule, the CME 
is essentially saying that this rule does not apply.  Turning off the 
validation is the simplest and most universal solution to the problem.  If 
the CME has a habit of sending you messages from other sessions, then there 
is a bigger problem they need to address.

--oren

----- Original Message ----- 
From: "Jain, Anil" <Ani...@rb...>
To: "Oren Miller" <or...@qu...>; "rho" <tia...@ya...>; 
<qui...@li...>
Sent: Wednesday, May 10, 2006 12:18 PM
Subject: RE: [Quickfix-developers] isCorrectCompID


I do not understand your suggestion to make it configurable.
The validation, if it is needed, must be there, now that a pattern needs to 
be validated, rather than a static data.
But, then neither have I used CME fault tolerance, nor I have sufficient QF 
experience to encounter a failed validation in general.

Anil Jain

-----Original Message-----
From: qui...@li...
[mailto:qui...@li...]On Behalf Of
Oren Miller
Sent: Wednesday, May 10, 2006 1:02 PM
To: rho; qui...@li...
Subject: Re: [Quickfix-developers] isCorrectCompID


QuickFIX Documentation: 
http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX Support: http://www.quickfixengine.org/services.html

Yeah, this is just a quick workaround.  In the end we will probably need to
add another validation config setting such as ValidateSenderCompID.

--oren

----- Original Message ----- 
From: "rho" <tia...@ya...>
To: <qui...@li...>
Sent: Wednesday, May 10, 2006 11:53 AM
Subject: Re: [Quickfix-developers] isCorrectCompID


> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
>
> The easy way to fix it is to modify the function one way or another. But
> that
> would mean a change of the quickfix library. I tried not to change the
> quickfix library.
>
> --
_______________________________________________________________________

This E-Mail (including any attachments) may contain privileged or 
confidential information.  It is intended only for the addressee(s) 
indicated above.
The sender does not waive any of its rights, privileges or other protections 
respecting this information.
Any distribution, copying or other use of this E-Mail or the information it 
contains, by other than an intended recipient, is not sanctioned and is 
prohibited.
If you received this E-Mail in error, please delete it and advise the sender 
(by return E-Mail or otherwise) immediately.

This E-Mail (including any attachments) has been scanned for viruses.
It is believed to be free of any virus or other defect that might affect any 
computer system into which it is received and opened.
However, it is the responsibility of the recipient to ensure that it is 
virus free.
The sender accepts no responsibility for any loss or damage arising in any 
way from its use.

E-Mail received by or sent from RBC Capital Markets is subject to review by 
Supervisory personnel.
Such communications are retained and may be produced to regulatory 
authorities or others with legal rights to the information.



-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers

Re: [Quickfix-developers] isCorrectCompID

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

Well, the CME made the choice to break FIX compatibility by sending multiple 
comp ids on a single session.  Adding pattern matching or regex comparisons 
to compids adds a lot of complexity with no real tangible benefit.  The same 
goes for systems that choose to send some fields with no data.  Our solution 
is going to be to turn turn off that validation for all fields in those 
cases.  We don't intend on writing a validation system that will do that 
validation for some fields and not for others.  The added effort and 
complexity is just not worth it.

These are basic rules of the fix protocol.  By breaking this rule, the CME 
is essentially saying that this rule does not apply.  Turning off the 
validation is the simplest and most universal solution to the problem.  If 
the CME has a habit of sending you messages from other sessions, then there 
is a bigger problem they need to address.

--oren

----- Original Message ----- 
From: "Jain, Anil" <Ani...@rb...>
To: "Oren Miller" <or...@qu...>; "rho" <tia...@ya...>; 
<qui...@li...>
Sent: Wednesday, May 10, 2006 12:18 PM
Subject: RE: [Quickfix-developers] isCorrectCompID


I do not understand your suggestion to make it configurable.
The validation, if it is needed, must be there, now that a pattern needs to 
be validated, rather than a static data.
But, then neither have I used CME fault tolerance, nor I have sufficient QF 
experience to encounter a failed validation in general.

Anil Jain

-----Original Message-----
From: qui...@li...
[mailto:qui...@li...]On Behalf Of
Oren Miller
Sent: Wednesday, May 10, 2006 1:02 PM
To: rho; qui...@li...
Subject: Re: [Quickfix-developers] isCorrectCompID


QuickFIX Documentation: 
http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX Support: http://www.quickfixengine.org/services.html

Yeah, this is just a quick workaround.  In the end we will probably need to
add another validation config setting such as ValidateSenderCompID.

--oren

----- Original Message ----- 
From: "rho" <tia...@ya...>
To: <qui...@li...>
Sent: Wednesday, May 10, 2006 11:53 AM
Subject: Re: [Quickfix-developers] isCorrectCompID


> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
>
> The easy way to fix it is to modify the function one way or another. But
> that
> would mean a change of the quickfix library. I tried not to change the
> quickfix library.
>
> --
_______________________________________________________________________

This E-Mail (including any attachments) may contain privileged or 
confidential information.  It is intended only for the addressee(s) 
indicated above.
The sender does not waive any of its rights, privileges or other protections 
respecting this information.
Any distribution, copying or other use of this E-Mail or the information it 
contains, by other than an intended recipient, is not sanctioned and is 
prohibited.
If you received this E-Mail in error, please delete it and advise the sender 
(by return E-Mail or otherwise) immediately.

This E-Mail (including any attachments) has been scanned for viruses.
It is believed to be free of any virus or other defect that might affect any 
computer system into which it is received and opened.
However, it is the responsibility of the recipient to ensure that it is 
virus free.
The sender accepts no responsibility for any loss or damage arising in any 
way from its use.

E-Mail received by or sent from RBC Capital Markets is subject to review by 
Supervisory personnel.
Such communications are retained and may be produced to regulatory 
authorities or others with legal rights to the information.

[Quickfix-developers] CVS outage

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

In case anyone is not yet aware, sourceforge is experiencing a system wide 
CVS outage.  This affects both the public and ssh CVS systems.  This means 
that not only can the public not check out the latest code, but quickfix 
developers cannot currently commit changes.  According to their latest 
status update, CVS will not be back up until end of week.  They are also 
changing the infrastructure at the same time so the settings for connecting 
to CVS will likely change.

--oren 

RE: [Quickfix-developers] isCorrectCompID

[Jain, A. <Ani...@rb...>]

I do not understand your suggestion to make it configurable.
The validation, if it is needed, must be there, now that a pattern needs to=
 be validated, rather than a static data.
But, then neither have I used CME fault tolerance, nor I have sufficient QF=
 experience to encounter a failed validation in general.

Anil Jain

-----Original Message-----
From: qui...@li...
[mailto:qui...@li...]On Behalf Of
Oren Miller
Sent: Wednesday, May 10, 2006 1:02 PM
To: rho; qui...@li...
Subject: Re: [Quickfix-developers] isCorrectCompID


QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/ind=
ex.html
QuickFIX Support: http://www.quickfixengine.org/services.html

Yeah, this is just a quick workaround.  In the end we will probably need to=20
add another validation config setting such as ValidateSenderCompID.

--oren

----- Original Message -----=20
From: "rho" <tia...@ya...>
To: <qui...@li...>
Sent: Wednesday, May 10, 2006 11:53 AM
Subject: Re: [Quickfix-developers] isCorrectCompID


> QuickFIX Documentation:=20
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
>
> The easy way to fix it is to modify the function one way or another. But=20
> that
> would mean a change of the quickfix library. I tried not to change the
> quickfix library.
>
> --
_______________________________________________________________________

This E-Mail (including any attachments) may contain privileged or confident=
ial information.  It is intended only for the addressee(s) indicated above.
The sender does not waive any of its rights, privileges or other protection=
s respecting this information. =20
Any distribution, copying or other use of this E-Mail or the information it=
 contains, by other than an intended recipient, is not sanctioned and is pr=
ohibited.
If you received this E-Mail in error, please delete it and advise the sende=
r (by return E-Mail or otherwise) immediately.

This E-Mail (including any attachments) has been scanned for viruses.=20
It is believed to be free of any virus or other defect that might affect an=
y computer system into which it is received and opened.=20
However, it is the responsibility of the recipient to ensure that it is vir=
us free.=20
The sender accepts no responsibility for any loss or damage arising in any =
way from its use.

E-Mail received by or sent from RBC Capital Markets is subject to review by=
 Supervisory personnel.=20
Such communications are retained and may be produced to regulatory authorit=
ies or others with legal rights to the information.

[Quickfix-developers] postgres store issue

[Sean K. <sea...@pi...>]

Hello All,

We've encountered an issue with the postgres message store / log =
involving messages that have tags populated with text containing a " ' =
".  Because this is the default text delimiter in postgres, it breaks =
the insert.  I am currently patching my version of the library, but this =
should probably be fixed for a future release of QuickFix.  It may also =
be a problem in the other DB stores...

Thanks!

Sean Kirkpatrick