quickfix-developers — QuickFIX developers forum

[Quickfix-developers] QFJ: Test message => Heartbeat response => Disconnect

[Shepheard, T. (London) <Tob...@ml...>]

I'm seeing some unexpected behaviour after sending a Test message and
getting a Heartbeat response back. This is with the QFJ, taken from CVS
head ~1 week ago.
=20
Here's what I see in the logs at my end (XXX to replace 3rd party)
[2006-02-02 18:34:19,445][INFO ] msg.incoming:
FIX.4.4:ML_RTFI_DEV1->XXXXFIXTEST1:
8=3DFIX.4.4=019=3D121=0135=3DH=0134=3D1107=0149=3DXXXXFIXTEST1=0150=3DTob=
y_Shepheard@MLRX=0152=3D2
0060202-18:34:19.336=0156=3DML_RTFI_DEV1=0111=3D5.1.152297=0154=3D1=0155=3D=
[N/A]=0110=3D047

......

protocol.XXXXXXXQFApplication: Sending FIX admin message
(1)8=3DFIX.4.4=019=3D78=0135=3D1=0134=3D954=0149=3DML_RTFI_DEV1=0152=3D20=
060202-18:35:05.383=015
6=3DXXXXFIXTEST1=01112=3DTEST=0110=3D147=01

[2006-02-02 18:35:05,383][INFO ] msg.outgoing:
FIX.4.4:ML_RTFI_DEV1->XXXXFIXTEST1:
8=3DFIX.4.4=019=3D78=0135=3D1=0134=3D954=0149=3DML_RTFI_DEV1=0152=3D20060=
202-18:35:05.383=0156=3DX
XXXFIXTEST1=01112=3DTEST=0110=3D147=01

[2006-02-02 18:35:05,430][INFO ] quickfixj.event:
FIX.4.4:ML_RTFI_DEV1->XXXXFIXTEST1: Sent test request TEST

[2006-02-02 18:35:32,399][INFO ] quickfixj.event:
FIX.4.4:ML_RTFI_DEV1->XXXXFIXTEST1: Timed out waiting for heartbeat

[2006-02-02 18:35:32,399][INFO ] quickfixj.event:
FIX.4.4:ML_RTFI_DEV1->XXXXFIXTEST1: Disconnecting

=20
From the logs, no great shakes - we sent a Test request, got no
response, timed out due to receiving no messages and disconnected.
However..... a network snoop reveals the following:
=20
=20
8=3DFIX.4.4.9=3D78.35=3D1.34=3D954.49=3DML_RTFI_DEV1.52=3D20060202-18:35:=
05.383.56=3DR
EUTFIXTEST1.112=3DTEST.10=3D147.   =3D>>>>> this is my Test message
=20
8=3DFIX.4.4.9=3D79.35=3D0.34=3D1115.49=3DREUTFIXTEST1.52=3D20060202-18:35=
:05.374.56=3D
ML_RTFI_DEV1.112=3DTEST.10=3D185.   <<<<<<=3D This is a heartbeat =
message
response
=20
=20
The heartbeat message was received ~20ms after the Test message, but due
to some slight difference in clock times, the Sending Time (52) makes it
look like it came a fraction earlier. I'm not sure if this is perhaps
part of the problem? There doesn't seem to be any sign of this heartbeat
being received on my side, which leads me to believe there's something
fishy here, but I'm not sure if its related to the TEST message or the
SendingTime being prior to my SystemTime when I'm processing it, or
something else altogether.
=20
The time between the last recorded message I received (the resend
request at the top, which I ignored) and the disconnect is ~73 seconds,
matching the 2.4*heartbeat interval in the code. So everything points to
he heartbeat message from the 3rd party, send almost immediately after
the Test message request, being totally ignored.... any ideas why?
=20
MTIA,
Toby
--------------------------------------------------------

If you are not an intended recipient of this e-mail, please notify the =
sender, delete it and do not read, act upon, print, disclose, copy, =
retain or redistribute it. Click here for important additional terms =
relating to this e-mail.     http://www.ml.com/email_terms/
--------------------------------------------------------

[Quickfix-developers] QuickFIX/J updates and new features

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

I've updated the QuickFIX/J CSV HEAD with most of the features in the
1.11.0 version. I'm not currently planning to port the MSSQL and
PostgreSQL-specific classes but those databases can be accessed using
the existing JdbcLog and JdbcStore classes.
=20
I've also added some new features to the QuickFIX/J CVS head.
=20
I've added simple failover support for QF/J acceptors. When using a
MessageStore that supports shared data (FileStore, JdbcStore,
SleepycatStore) and implements the new RefreshableMessageStore
interface, the Session can be configured to refresh the store
information upon logon. You would typically run two acceptor processes
using a shared message store. One process would be the active acceptor
and the other would be the standby for any specific session. If one
acceptor process dies, the client (assuming they have been configured
with failover addresses) will attempt to logon to the other acceptor.
When they do, the message store for that session will be refreshed and
the session should continue normally. I've tried this with Banzai and
two Order Executors and it appears to work well. Note that this approach
doesn''t require that each acceptor is globally in an active or standby
role. Since that role is session-specific, both acceptors could be be
actively supporting sessions and when one node dies all the sessions on
that node will be automatically switched to the other node. This is
implemented simply by specifying the order of the failover addresses in
the QF settings file so that some clients initially connect to one node
and others connect to the other node. One weakness with this scenario is
that there's no way to redistribute the sessions to the two nodes once
the dead node is restarted. That can be added as future capability. I'll
provide more documentation and configuration scenarios in the
documentation (possibly after the beta 3 release).
=20
I've also created a first implementation of QF message component
classes. They still need more work, but you can try them by generating
the classes using the code generator in the CVS HEAD. The components are
in the quickfix.fix43.component and quickfix.fix44.component packages.
=20
Steve Bate
Smart Trade Technologies
Phone: +33 4 42 90 03 97
http://www.smart-trade.net/
=20
=20

Re: [Quickfix-developers] TradeCapture Request Report

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

On 2/2/06, Shankar Krishnan <skr...@jw...> wrote:
>
>  Thanks,  I looked under QuickFix44, hence the issue.
>

Fields are all in the QuickFix namespace since they're not really
version-specific.


--
Caleb Epstein
caleb dot epstein at gmail dot com

RE: [Quickfix-developers] TradeCapture Request Report

[Shankar K. <skr...@jw...>]

 

Thanks,  I looked under QuickFix44, hence the issue.

 

Tks

 

  _____  

From: Caleb Epstein [mailto:cal...@gm...] 
Sent: Thursday, February 02, 2006 11:13 AM
To: Shankar Krishnan
Cc: qui...@li...
Subject: Re: [Quickfix-developers] TradeCapture Request Report

 

On 2/2/06, Shankar Krishnan <skr...@jw... <mailto:skr...@jw...> >
wrote:

Per my counterparty spec (based on FIX 4.4) Trade Capture Report Request
need the following fields

MsgType

TradeRequestID

TradeRequestType

SubscriptionRequestType

NoDates

TradeDate

The function with no arguments does not allow me to set subscription request
using the message,set

Method .


What do you mean it doesn't allow you to set that field? The class offers:

    public void set( QuickFix.SubscriptionRequestType value)

As well as getters/setters for all other optional fields.


-- 
Caleb Epstein
caleb dot epstein at gmail dot com 

Re: [Quickfix-developers] TradeCapture Request Report

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

On 2/2/06, Shankar Krishnan <skr...@jw...> wrote:
>
> Per my counterparty spec (based on FIX 4.4) Trade Capture Report Request
> need the following fields
>
> MsgType
>
> TradeRequestID
>
> TradeRequestType
>
> SubscriptionRequestType
>
> NoDates
>
> TradeDate
>
> The function with no arguments does not allow me to set subscription
> request using the message,set
>
> Method .
>

What do you mean it doesn't allow you to set that field? The class offers:

    public void set(QuickFix.SubscriptionRequestType value)

As well as getters/setters for all other optional fields.

--
Caleb Epstein
caleb dot epstein at gmail dot com

[Quickfix-developers] TradeCapture Request Report

[Shankar K. <skr...@jw...>]

 

Per my counterparty spec (based on FIX 4.4) Trade Capture Report Request
need the following fields

 

MsgType

TradeRequestID

TradeRequestType

SubscriptionRequestType

NoDates

TradeDate

 

 

I am constructing the message the following way.

 

QuickFix44.TradeCaptureReportRequest message = new
QuickFix44.TradeCaptureReportRequest();

The above highlighted function takes only 2 arguments traderequestID and
trade requestType !

 

The function with no arguments does not allow me to set subscription request
using the message,set

Method .

 

Any suggestions.

 

Thanks

 

RE: [Quickfix-developers] Public access to calculateLength and calculateTotal in C#

[Mike L. <Mik...@tr...>]

OK that's great you guys think of everything =3D)  At least by figuring
out how to expose the method in the C++ I got a better handle on how the
classes are structured.  Sheesh, you guys make my life too easy, I might
actually have to do work around here =3D)  Thanks Oren!

Michael J Lee
Software Engineer
Trading Systems Technology

Tradition North America
75 Park Place
4th Floor
New York NY 10007
Phone: 212.791.6668
Fax: 212.791.3463=20

-----Original Message-----
From: Oren Miller [mailto:or...@qu...]=20
Sent: Wednesday, February 01, 2006 6:15 PM
To: Mike Lee
Cc: qui...@li...
Subject: Re: [Quickfix-developers] Public access to calculateLength and
calculateTotal in C#

Yeah, this will be taken care of for you with sendToTarget.  Even if you

did put a value in for those fields, they would just get overwritten by=20
QuickFIX.

--oren

Mike Lee wrote:

>QuickFIX Documentation:
http://www.quickfixengine.org/quickfix/doc/html/index.html
>QuickFIX Support: http://www.quickfixengine.org/services.html
>
>Well I'm converting 4.0 messages to 4.2 and back again.  I'm trying to
>keep all the same values (if they correspond) for the fields.  So for
>example Heartbeat is received in 4.0 I create a 4.2 Heartbeat then
>proceed to copy header, message and trailer values from the 4.0 message
>to the 4.2 message and since I'm changing the values within the message
>I want to be able to set the length and the checksum before I send it
>out.  Does sendToTarget() put those values in before I send?  Does it
>check those values?  Thanks Oren!
>
>Michael J Lee
>Software Engineer
>Trading Systems Technology
>
>Tradition North America
>75 Park Place
>4th Floor
>New York NY 10007
>Phone: 212.791.6668
>Fax: 212.791.3463=20
>
>-----Original Message-----
>From: Oren Miller [mailto:or...@qu...]=20
>Sent: Wednesday, February 01, 2006 2:54 PM
>To: Mike Lee
>Cc: qui...@li...
>Subject: Re: [Quickfix-developers] Public access to calculateLength and
>calculateTotal in C#
>
>What is the intended use?  QuickFIX will place of values of these for=20
>you into the Length and Checksum fields when toString is called.
>
>--oren
>
>Mike Lee wrote:
>
> =20
>
>>QuickFIX Documentation:
>>   =20
>>
>http://www.quickfixengine.org/quickfix/doc/html/index.html
> =20
>
>>QuickFIX Support: http://www.quickfixengine.org/services.html
>>
>>
>>FIX::Message::calculateLength()
>>FIX::Message::calculateTotal()
>>
>>Besides changing the c++ code, is there any way to access these with
>>   =20
>>
>C#?
> =20
>
>>Can it be put into some static class that accepts a message and spits
>>out the value?  Or is there some method available already in C# that
>>will calculate these for me?
>>
>>Michael J Lee
>>Software Engineer
>>Trading Systems Technology
>>
>>Tradition North America
>>75 Park Place
>>4th Floor
>>New York NY 10007
>>Phone: 212.791.6668
>>Fax: 212.791.3463=20
>>
>>
>>
>>**********************************************************************
*
>>   =20
>>
>************
> =20
>
>>This message and any files transmitted with it are confidential and
>>   =20
>>
>intended solely for the use of the individual or entity to whom it is
>addressed. It may contain sensitive and private proprietary or legally
>privileged information. No confidentiality or privilege is waived or
>lost by any mistransmission. If you are not the intended recipient,
>please immediately delete it and all copies of it from your system,
>destroy any hard copies of it and notify the sender. You must not,
>directly or indirectly, use, disclose, distribute, print, or copy any
>part of this message if you are not the intended recipient. Tradition
>Asiel Securities Inc. and Tradition (North America) Inc. reserve the
>right to monitor all e-mail communications through its networks. Any
>views expressed in this message are those of the individual sender,
>except where the message states otherwise and the sender is authorized
>to state them.
> =20
>
>>Unless otherwise stated, any pricing information given in this message
>>   =20
>>
>is indicative only, is subject to change and does not constitute an
>offer to deal at any price quoted. Any reference to the terms of
>executed transactions should be treated as preliminary only and subject
>to our formal written confirmation. Tradition Asiel Securities Inc. and
>Tradition (North America) Inc. are not responsible for any
>recommendation, solicitation, offer or agreement or any information
>about any transaction, customer account or account activity contained
in
>this communication.
> =20
>
>>This footnote also confirms that this email message has been swept by
>>Anti-virus detection software for the presence of computer viruses.
>>
>>**********************************************************************
*
>>   =20
>>
>************
> =20
>
>>
>>
>>-------------------------------------------------------
>>This SF.net email is sponsored by: Splunk Inc. Do you grep through log
>>   =20
>>
>files
> =20
>
>>for problems?  Stop!  Download the new AJAX search engine that makes
>>searching your log files as easy as surfing the  web.  DOWNLOAD
SPLUNK!
>>http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=103432&bid#0486&dat=121642
>>_______________________________________________
>>Quickfix-developers mailing list
>>Qui...@li...
>>https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>>
>>
>>=20
>>
>>   =20
>>
>
>
>
>***********************************************************************
************
>
>This message and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom it is
addressed. It may contain sensitive and private proprietary or legally
privileged information. No confidentiality or privilege is waived or
lost by any mistransmission. If you are not the intended recipient,
please immediately delete it and all copies of it from your system,
destroy any hard copies of it and notify the sender. You must not,
directly or indirectly, use, disclose, distribute, print, or copy any
part of this message if you are not the intended recipient. Tradition
Asiel Securities Inc. and Tradition (North America) Inc. reserve the
right to monitor all e-mail communications through its networks. Any
views expressed in this message are those of the individual sender,
except where the message states otherwise and the sender is authorized
to state them.
>
>Unless otherwise stated, any pricing information given in this message
is indicative only, is subject to change and does not constitute an
offer to deal at any price quoted. Any reference to the terms of
executed transactions should be treated as preliminary only and subject
to our formal written confirmation. Tradition Asiel Securities Inc. and
Tradition (North America) Inc. are not responsible for any
recommendation, solicitation, offer or agreement or any information
about any transaction, customer account or account activity contained in
this communication.
>
>This footnote also confirms that this email message has been swept by
>Anti-virus detection software for the presence of computer viruses.
>
>***********************************************************************
************
>
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc. Do you grep through log
files
>for problems?  Stop!  Download the new AJAX search engine that makes
>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=103432&bid#0486&dat=121642
>_______________________________________________
>Quickfix-developers mailing list
>Qui...@li...
>https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>
>
> =20
>



***************************************************************************=
********

This message and any files transmitted with it are confidential and intende=
d solely for the use of the individual or entity to whom it is addressed. I=
t may contain sensitive and private proprietary or legally privileged infor=
mation. No confidentiality or privilege is waived or lost by any mistransmi=
ssion. If you are not the intended recipient, please immediately delete it =
and all copies of it from your system, destroy any hard copies of it and no=
tify the sender. You must not, directly or indirectly, use, disclose, distr=
ibute, print, or copy any part of this message if you are not the intended =
recipient. Tradition Asiel Securities Inc. and Tradition (North America) In=
c. reserve the right to monitor all e-mail communications through its netwo=
rks. Any views expressed in this message are those of the individual sender=
, except where the message states otherwise and the sender is authorized to=
 state them.

Unless otherwise stated, any pricing information given in this message is i=
ndicative only, is subject to change and does not constitute an offer to de=
al at any price quoted. Any reference to the terms of executed transactions=
 should be treated as preliminary only and subject to our formal written co=
nfirmation. Tradition Asiel Securities Inc. and Tradition (North America) I=
nc. are not responsible for any recommendation, solicitation, offer or agre=
ement or any information about any transaction, customer account or account=
 activity contained in this communication.

This footnote also confirms that this email message has been swept by
Anti-virus detection software for the presence of computer viruses.

***************************************************************************=
********

Re: [Quickfix-developers] Public access to calculateLength and calculateTotal in C#

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

Yeah, this will be taken care of for you with sendToTarget.  Even if you =

did put a value in for those fields, they would just get overwritten by=20
QuickFIX.

--oren

Mike Lee wrote:

>QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/=
index.html
>QuickFIX Support: http://www.quickfixengine.org/services.html
>
>Well I'm converting 4.0 messages to 4.2 and back again.  I'm trying to
>keep all the same values (if they correspond) for the fields.  So for
>example Heartbeat is received in 4.0 I create a 4.2 Heartbeat then
>proceed to copy header, message and trailer values from the 4.0 message
>to the 4.2 message and since I'm changing the values within the message
>I want to be able to set the length and the checksum before I send it
>out.  Does sendToTarget() put those values in before I send?  Does it
>check those values?  Thanks Oren!
>
>Michael J Lee
>Software Engineer
>Trading Systems Technology
>
>Tradition North America
>75 Park Place
>4th Floor
>New York NY 10007
>Phone: 212.791.6668
>Fax: 212.791.3463=20
>
>-----Original Message-----
>From: Oren Miller [mailto:or...@qu...]=20
>Sent: Wednesday, February 01, 2006 2:54 PM
>To: Mike Lee
>Cc: qui...@li...
>Subject: Re: [Quickfix-developers] Public access to calculateLength and
>calculateTotal in C#
>
>What is the intended use?  QuickFIX will place of values of these for=20
>you into the Length and Checksum fields when toString is called.
>
>--oren
>
>Mike Lee wrote:
>
> =20
>
>>QuickFIX Documentation:
>>   =20
>>
>http://www.quickfixengine.org/quickfix/doc/html/index.html
> =20
>
>>QuickFIX Support: http://www.quickfixengine.org/services.html
>>
>>
>>FIX::Message::calculateLength()
>>FIX::Message::calculateTotal()
>>
>>Besides changing the c++ code, is there any way to access these with
>>   =20
>>
>C#?
> =20
>
>>Can it be put into some static class that accepts a message and spits
>>out the value?  Or is there some method available already in C# that
>>will calculate these for me?
>>
>>Michael J Lee
>>Software Engineer
>>Trading Systems Technology
>>
>>Tradition North America
>>75 Park Place
>>4th Floor
>>New York NY 10007
>>Phone: 212.791.6668
>>Fax: 212.791.3463=20
>>
>>
>>
>>***********************************************************************=

>>   =20
>>
>************
> =20
>
>>This message and any files transmitted with it are confidential and
>>   =20
>>
>intended solely for the use of the individual or entity to whom it is
>addressed. It may contain sensitive and private proprietary or legally
>privileged information. No confidentiality or privilege is waived or
>lost by any mistransmission. If you are not the intended recipient,
>please immediately delete it and all copies of it from your system,
>destroy any hard copies of it and notify the sender. You must not,
>directly or indirectly, use, disclose, distribute, print, or copy any
>part of this message if you are not the intended recipient. Tradition
>Asiel Securities Inc. and Tradition (North America) Inc. reserve the
>right to monitor all e-mail communications through its networks. Any
>views expressed in this message are those of the individual sender,
>except where the message states otherwise and the sender is authorized
>to state them.
> =20
>
>>Unless otherwise stated, any pricing information given in this message
>>   =20
>>
>is indicative only, is subject to change and does not constitute an
>offer to deal at any price quoted. Any reference to the terms of
>executed transactions should be treated as preliminary only and subject
>to our formal written confirmation. Tradition Asiel Securities Inc. and
>Tradition (North America) Inc. are not responsible for any
>recommendation, solicitation, offer or agreement or any information
>about any transaction, customer account or account activity contained in=

>this communication.
> =20
>
>>This footnote also confirms that this email message has been swept by
>>Anti-virus detection software for the presence of computer viruses.
>>
>>***********************************************************************=

>>   =20
>>
>************
> =20
>
>>
>>
>>-------------------------------------------------------
>>This SF.net email is sponsored by: Splunk Inc. Do you grep through log
>>   =20
>>
>files
> =20
>
>>for problems?  Stop!  Download the new AJAX search engine that makes
>>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!=

>>http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=103432&bid#0486&dat=121642
>>_______________________________________________
>>Quickfix-developers mailing list
>>Qui...@li...
>>https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>>
>>
>>=20
>>
>>   =20
>>
>
>
>
>************************************************************************=
***********
>
>This message and any files transmitted with it are confidential and inte=
nded solely for the use of the individual or entity to whom it is address=
ed. It may contain sensitive and private proprietary or legally privilege=
d information. No confidentiality or privilege is waived or lost by any m=
istransmission. If you are not the intended recipient, please immediately=
 delete it and all copies of it from your system, destroy any hard copies=
 of it and notify the sender. You must not, directly or indirectly, use, =
disclose, distribute, print, or copy any part of this message if you are =
not the intended recipient. Tradition Asiel Securities Inc. and Tradition=
 (North America) Inc. reserve the right to monitor all e-mail communicati=
ons through its networks. Any views expressed in this message are those o=
f the individual sender, except where the message states otherwise and th=
e sender is authorized to state them.
>
>Unless otherwise stated, any pricing information given in this message i=
s indicative only, is subject to change and does not constitute an offer =
to deal at any price quoted. Any reference to the terms of executed trans=
actions should be treated as preliminary only and subject to our formal w=
ritten confirmation. Tradition Asiel Securities Inc. and Tradition (North=
 America) Inc. are not responsible for any recommendation, solicitation, =
offer or agreement or any information about any transaction, customer acc=
ount or account activity contained in this communication.
>
>This footnote also confirms that this email message has been swept by
>Anti-virus detection software for the presence of computer viruses.
>
>************************************************************************=
***********
>
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc. Do you grep through log f=
iles
>for problems?  Stop!  Download the new AJAX search engine that makes
>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=103432&bid#0486&dat=121642
>_______________________________________________
>Quickfix-developers mailing list
>Qui...@li...
>https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>
>
> =20
>

RE: [Quickfix-developers] Public access to calculateLength and calculateTotal in C#

[Mike L. <Mik...@tr...>]

Well I'm converting 4.0 messages to 4.2 and back again.  I'm trying to
keep all the same values (if they correspond) for the fields.  So for
example Heartbeat is received in 4.0 I create a 4.2 Heartbeat then
proceed to copy header, message and trailer values from the 4.0 message
to the 4.2 message and since I'm changing the values within the message
I want to be able to set the length and the checksum before I send it
out.  Does sendToTarget() put those values in before I send?  Does it
check those values?  Thanks Oren!

Michael J Lee
Software Engineer
Trading Systems Technology

Tradition North America
75 Park Place
4th Floor
New York NY 10007
Phone: 212.791.6668
Fax: 212.791.3463=20

-----Original Message-----
From: Oren Miller [mailto:or...@qu...]=20
Sent: Wednesday, February 01, 2006 2:54 PM
To: Mike Lee
Cc: qui...@li...
Subject: Re: [Quickfix-developers] Public access to calculateLength and
calculateTotal in C#

What is the intended use?  QuickFIX will place of values of these for=20
you into the Length and Checksum fields when toString is called.

--oren

Mike Lee wrote:

>QuickFIX Documentation:
http://www.quickfixengine.org/quickfix/doc/html/index.html
>QuickFIX Support: http://www.quickfixengine.org/services.html
>
>
>FIX::Message::calculateLength()
>FIX::Message::calculateTotal()
>
>Besides changing the c++ code, is there any way to access these with
C#?
>Can it be put into some static class that accepts a message and spits
>out the value?  Or is there some method available already in C# that
>will calculate these for me?
>
>Michael J Lee
>Software Engineer
>Trading Systems Technology
>
>Tradition North America
>75 Park Place
>4th Floor
>New York NY 10007
>Phone: 212.791.6668
>Fax: 212.791.3463=20
>
>
>
>***********************************************************************
************
>
>This message and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom it is
addressed. It may contain sensitive and private proprietary or legally
privileged information. No confidentiality or privilege is waived or
lost by any mistransmission. If you are not the intended recipient,
please immediately delete it and all copies of it from your system,
destroy any hard copies of it and notify the sender. You must not,
directly or indirectly, use, disclose, distribute, print, or copy any
part of this message if you are not the intended recipient. Tradition
Asiel Securities Inc. and Tradition (North America) Inc. reserve the
right to monitor all e-mail communications through its networks. Any
views expressed in this message are those of the individual sender,
except where the message states otherwise and the sender is authorized
to state them.
>
>Unless otherwise stated, any pricing information given in this message
is indicative only, is subject to change and does not constitute an
offer to deal at any price quoted. Any reference to the terms of
executed transactions should be treated as preliminary only and subject
to our formal written confirmation. Tradition Asiel Securities Inc. and
Tradition (North America) Inc. are not responsible for any
recommendation, solicitation, offer or agreement or any information
about any transaction, customer account or account activity contained in
this communication.
>
>This footnote also confirms that this email message has been swept by
>Anti-virus detection software for the presence of computer viruses.
>
>***********************************************************************
************
>
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc. Do you grep through log
files
>for problems?  Stop!  Download the new AJAX search engine that makes
>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=103432&bid#0486&dat=121642
>_______________________________________________
>Quickfix-developers mailing list
>Qui...@li...
>https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>
>
> =20
>



***************************************************************************=
********

This message and any files transmitted with it are confidential and intende=
d solely for the use of the individual or entity to whom it is addressed. I=
t may contain sensitive and private proprietary or legally privileged infor=
mation. No confidentiality or privilege is waived or lost by any mistransmi=
ssion. If you are not the intended recipient, please immediately delete it =
and all copies of it from your system, destroy any hard copies of it and no=
tify the sender. You must not, directly or indirectly, use, disclose, distr=
ibute, print, or copy any part of this message if you are not the intended =
recipient. Tradition Asiel Securities Inc. and Tradition (North America) In=
c. reserve the right to monitor all e-mail communications through its netwo=
rks. Any views expressed in this message are those of the individual sender=
, except where the message states otherwise and the sender is authorized to=
 state them.

Unless otherwise stated, any pricing information given in this message is i=
ndicative only, is subject to change and does not constitute an offer to de=
al at any price quoted. Any reference to the terms of executed transactions=
 should be treated as preliminary only and subject to our formal written co=
nfirmation. Tradition Asiel Securities Inc. and Tradition (North America) I=
nc. are not responsible for any recommendation, solicitation, offer or agre=
ement or any information about any transaction, customer account or account=
 activity contained in this communication.

This footnote also confirms that this email message has been swept by
Anti-virus detection software for the presence of computer viruses.

***************************************************************************=
********

Re: [Quickfix-developers] Public access to calculateLength and calculateTotal in C#

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

What is the intended use?  QuickFIX will place of values of these for=20
you into the Length and Checksum fields when toString is called.

--oren

Mike Lee wrote:

>QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/=
index.html
>QuickFIX Support: http://www.quickfixengine.org/services.html
>
>
>FIX::Message::calculateLength()
>FIX::Message::calculateTotal()
>
>Besides changing the c++ code, is there any way to access these with C#?=

>Can it be put into some static class that accepts a message and spits
>out the value?  Or is there some method available already in C# that
>will calculate these for me?
>
>Michael J Lee
>Software Engineer
>Trading Systems Technology
>
>Tradition North America
>75 Park Place
>4th Floor
>New York NY 10007
>Phone: 212.791.6668
>Fax: 212.791.3463=20
>
>
>
>************************************************************************=
***********
>
>This message and any files transmitted with it are confidential and inte=
nded solely for the use of the individual or entity to whom it is address=
ed. It may contain sensitive and private proprietary or legally privilege=
d information. No confidentiality or privilege is waived or lost by any m=
istransmission. If you are not the intended recipient, please immediately=
 delete it and all copies of it from your system, destroy any hard copies=
 of it and notify the sender. You must not, directly or indirectly, use, =
disclose, distribute, print, or copy any part of this message if you are =
not the intended recipient. Tradition Asiel Securities Inc. and Tradition=
 (North America) Inc. reserve the right to monitor all e-mail communicati=
ons through its networks. Any views expressed in this message are those o=
f the individual sender, except where the message states otherwise and th=
e sender is authorized to state them.
>
>Unless otherwise stated, any pricing information given in this message i=
s indicative only, is subject to change and does not constitute an offer =
to deal at any price quoted. Any reference to the terms of executed trans=
actions should be treated as preliminary only and subject to our formal w=
ritten confirmation. Tradition Asiel Securities Inc. and Tradition (North=
 America) Inc. are not responsible for any recommendation, solicitation, =
offer or agreement or any information about any transaction, customer acc=
ount or account activity contained in this communication.
>
>This footnote also confirms that this email message has been swept by
>Anti-virus detection software for the presence of computer viruses.
>
>************************************************************************=
***********
>
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc. Do you grep through log f=
iles
>for problems?  Stop!  Download the new AJAX search engine that makes
>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=103432&bid#0486&dat=121642
>_______________________________________________
>Quickfix-developers mailing list
>Qui...@li...
>https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>
>
> =20
>

[Quickfix-developers] Public access to calculateLength and calculateTotal in C#

[Mike L. <Mik...@tr...>]

FIX::Message::calculateLength()
FIX::Message::calculateTotal()

Besides changing the c++ code, is there any way to access these with C#?
Can it be put into some static class that accepts a message and spits
out the value?  Or is there some method available already in C# that
will calculate these for me?

Michael J Lee
Software Engineer
Trading Systems Technology

Tradition North America
75 Park Place
4th Floor
New York NY 10007
Phone: 212.791.6668
Fax: 212.791.3463=20



***************************************************************************=
********

This message and any files transmitted with it are confidential and intende=
d solely for the use of the individual or entity to whom it is addressed. I=
t may contain sensitive and private proprietary or legally privileged infor=
mation. No confidentiality or privilege is waived or lost by any mistransmi=
ssion. If you are not the intended recipient, please immediately delete it =
and all copies of it from your system, destroy any hard copies of it and no=
tify the sender. You must not, directly or indirectly, use, disclose, distr=
ibute, print, or copy any part of this message if you are not the intended =
recipient. Tradition Asiel Securities Inc. and Tradition (North America) In=
c. reserve the right to monitor all e-mail communications through its netwo=
rks. Any views expressed in this message are those of the individual sender=
, except where the message states otherwise and the sender is authorized to=
 state them.

Unless otherwise stated, any pricing information given in this message is i=
ndicative only, is subject to change and does not constitute an offer to de=
al at any price quoted. Any reference to the terms of executed transactions=
 should be treated as preliminary only and subject to our formal written co=
nfirmation. Tradition Asiel Securities Inc. and Tradition (North America) I=
nc. are not responsible for any recommendation, solicitation, offer or agre=
ement or any information about any transaction, customer account or account=
 activity contained in this communication.

This footnote also confirms that this email message has been swept by
Anti-virus detection software for the presence of computer viruses.

***************************************************************************=
********

RE: [Quickfix-developers] messages_log table entries

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

In our implementation, we derive FIX::FileLogFactory anyway to put timestam=
p with sufficient granularity and made this option configurable. In a commo=
n file, a leading direction indicator character would be preferred, so that=
 a message need not be parsed for this purpose, and is trivial to separate,=
 cut and slice.
What I would really like is that the source code make it easy to put timest=
amp ahead of  =20
anything else, in the derived class.

Thanks for the new and improved QuickFIX!

Anil
-----Original Message-----
From: qui...@li...
[mailto:qui...@li...]On Behalf Of
Oren Miller
Sent: Wednesday, February 01, 2006 11:34 AM
To: Brian Erst
Cc: Sean Kirkpatrick; qui...@li...
Subject: Re: [Quickfix-developers] messages_log table entries


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

Well, the message itself has the CompIDs in the correct place.  We are=20
*not* changing the contents of the message at all.  The message column=20
always reflects exactly what was sent or received.  We are just talking=20
about the database columns which identify the session.  This concept has=20
not changed from the previous release.  The incoming and outgoing tables=20
would contain the same values in these columns.  The only thing that has=20
happened is the tables have been consolidated to retain the sequence of=20
events.  All the data within the columns remains exactly the same.

I don't think it is a contrived scenario to have the counterparties=20
share the same database.  Many people use FIX for interprocess=20
communication within their internal systems.  Those systems often share=20
the same database.  This is a setup I've seen several times, so I do=20
believe its support is necessary.

The only problem with the separate log files was again, losing the=20
sequence of events.  It actually made it very difficult to debug=20
scenarios, especially when logs were posted to the mailing list and=20
extra explanation had to be provided to indicate what happened in what=20
order (if it could be determined at all).  If we do go about supporting=20
one or two files, I would definately make one file the default for this=20
reason.  It also seems to me to be the overall preference of the=20
community, but I'd like to hear additional comments.

Unfortunately in the log file it is rather difficult to add metadata, as=20
then the file is no longer pure fix which could give it problems with=20
some utilities.  This precludes the file from having any sort of=20
incoming/outgoing type metadata.

--oren

Brian Erst wrote:

>Oren -
>
>Is that actually a realistic scenario? I'm struggling to come up with a si=
tuation where someone would have a FIX acceptor and a FIX initiator talking=
 to each other and sharing the same database log file outside of a badly co=
nstructed test environment.
>
>Isn't the log file supposed to show what actually was received, as opposed=
 to some normalized view of the message data? Swapping the compIDs changes =
the message - if I want to reconstruct the message from the log table, I no=
w have to have program logic that can figure out which direction the messag=
e was going and denormalize the data. I can't say that I like that design c=
hoice.
>
>Of course, I vastly prefered having separate log files. I wouldn't have mi=
nded having the option to have a single log (especially if it was *in addit=
ion to* the separate logs), but I now have to modify my workflow (and some =
scripts) to deal with one log. It's kind of a drag.
>
>- Brian Erst
>Thynk Software, Inc.
>
>----- Original Message ----
>From: Oren Miller <or...@qu...>
>To: Sean Kirkpatrick <sea...@pi...>
>Cc: qui...@li...
>Sent: Wednesday, February 01, 2006 9:32:34 AM
>Subject: Re: [Quickfix-developers] messages_log table entries
>
>QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/in=
dex.html
>QuickFIX Support: http://www.quickfixengine.org/services.html
>
>Thanks Sean, I checked in a fix for the bug.
>
>We can't really alter the compid's as it would interfere with the=20
>counterparties log.  Imagine you have an acceptor running on one=20
>machine, and an initiator on another which are connected.  If they are=20
>sharing the same database, they will sort of walk all over each other=20
>and then things will really get confusing.  So the sessionid fields need=20
>to remain constant so they can act as a key.
>
>One option could be to add a direction column which indicates if a=20
>message is incoming or outgoing.
>
>--oren
>
>Sean Kirkpatrick wrote:
>
> =20
>
>>Hi Oren,
>>
>>I'm testing with 1.11.0 using the PostgreSQL store/log functionality=20
>>and had a question.  I think it's great that the incoming/outgoing=20
>>logs have been condensed into the single messages_log table, but I was=20
>>surprised that the sendercompid / targetcompid column values don't=20
>>change to indicate the direction of the message.  I'm guessing these=20
>>values are just set based on the sessionID for the configured=20
>>session.  Without this functionality the text field has to be grepped=20
>>through to determine the direction of the message.  Was this by design?
>>
>>I also found a slight bug in the sql scripts packaged to create the db=20
>>tables.  The messages_log_table.sql file still creates the=20
>>incoming_log table, rather than the messages_log table.  Changing the=20
>>name corrected the issue, but without the change, the Log doesn't=20
>>write any of the messages.  Just a head's up.
>>
>>Regards,
>>
>>Sean Kirkpatrick
>>
>>
>>
>>   =20
>>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc. Do you grep through log fil=
es
>for problems?  Stop!  Download the new AJAX search engine that makes
>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat=3D=
121642
>_______________________________________________
>Quickfix-developers mailing list
>Qui...@li...
>https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>
>
>
>
>
> =20
>


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat=3D1=
21642
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers
_______________________________________________________________________

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.

Re: [Quickfix-developers] messages_log table entries

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

Ok, I'll look into something along these lines.

--oren

Brian Erst wrote:

> That would be a great idea. Again, I think having a 1-file message log 
> is a great thing to offer - I'd just like to have the option of 
> retaining the existing behavior. In fact, I'd love to be able to do 
> both (3 log files - incoming, outgoing and interleaved). The more the 
> merrier! >grin<
>
> - Brian
>
> ----- Original Message ----
> From: Caleb Epstein <cal...@gm...>
> To: Brian Erst <azz...@ya...>
> Cc: Oren Miller <or...@qu...>; 
> qui...@li...
> Sent: Wednesday, February 01, 2006 11:03:12 AM
> Subject: Re: [Quickfix-developers] messages_log table entries
>
> On 2/1/06, *Brian Erst* <azz...@ya... 
> <mailto:azz...@ya...>> wrote:
>
>     and I can see how the new layout would be better for lots of
>     people, but people build systems that expect certain behavior and
>     when that behavior changes in a non-backward compatible way, it's
>     disruptive.
>
>
> Perhaps the 1-or-2 file behavior could be configurable through yet 
> another Session setting?
>
> -- 
> Caleb Epstein
> caleb dot epstein at gmail dot com

Re: [Quickfix-developers] messages_log table entries

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

That would be a great idea. Again, I think having a 1-file message log is a great thing to offer - I'd just like to have the option of retaining the existing behavior. In fact, I'd love to be able to do both (3 log files - incoming, outgoing and interleaved). The more the merrier! >grin<

- Brian

----- Original Message ----
From: Caleb Epstein <cal...@gm...>
To: Brian Erst <azz...@ya...>
Cc: Oren Miller <or...@qu...>; qui...@li...
Sent: Wednesday, February 01, 2006 11:03:12 AM
Subject: Re: [Quickfix-developers] messages_log table entries

On 2/1/06, Brian Erst <azz...@ya...> wrote: and I can see how the new layout would be better for lots of people, but people build systems that expect certain behavior and when that behavior changes in a non-backward compatible way, it's disruptive. 
Perhaps the 1-or-2 file behavior could be configurable through yet another Session setting?



-- 
Caleb Epstein
caleb dot epstein at gmail dot com 

Re: [Quickfix-developers] messages_log table entries

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

On 2/1/06, Brian Erst <azz...@ya...> wrote:
>
> and I can see how the new layout would be better for lots of people, but
> people build systems that expect certain behavior and when that behavior
> changes in a non-backward compatible way, it's disruptive.


Perhaps the 1-or-2 file behavior could be configurable through yet another
Session setting?

--
Caleb Epstein
caleb dot epstein at gmail dot com

Re: [Quickfix-developers] messages_log table entries

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

Oren -

I'm sorry that I confused the message data from the meta-data in the tables - it seemed unclear in the original posting. I agree with the others that there needs to be some easy way to extract sent from received messages - a direction flag sounds like it would work. 

Initiators and acceptors sharing the same database table still seems like a recipe for disaster to me, but as you've seen it in the real world, supporting it is a must.

I like having (the option of) separate incoming/outgoing log files as it makes it easy for me to concentrate on the counterparty's message flow - in my circumstance, we have a stable acceptor that doesn't change but a whole bunch of new counterparty initiators that usually have problems. I like being able to quickly select their problematic messages and send them an explanatory email with the attached messages. Also, as field ordering isn't particularly important in FIX, figuring out which messages are inbound and which are outbound can be a pain - the senderCompIDs are not going to conveniently line up. I've also written a few scripts that use the two files that will need to change. It's not a huge problem, and I can see how the new layout would be better for lots of people, but people build systems that expect certain behavior and when that behavior changes in a non-backward compatible way, it's disruptive. 

Compared to the work involved in creating QF, these are quibbles. Thanks for the good work on QF.

- Brian

----- Original Message ----
From: Oren Miller <or...@qu...>
To: Brian Erst <azz...@ya...>
Cc: Sean Kirkpatrick <sea...@pi...>; qui...@li...
Sent: Wednesday, February 01, 2006 10:34:06 AM
Subject: Re: [Quickfix-developers] messages_log table entries

Well, the message itself has the CompIDs in the correct place.  We are 
*not* changing the contents of the message at all.  The message column 
always reflects exactly what was sent or received.  We are just talking 
about the database columns which identify the session.  This concept has 
not changed from the previous release.  The incoming and outgoing tables 
would contain the same values in these columns.  The only thing that has 
happened is the tables have been consolidated to retain the sequence of 
events.  All the data within the columns remains exactly the same.

I don't think it is a contrived scenario to have the counterparties 
share the same database.  Many people use FIX for interprocess 
communication within their internal systems.  Those systems often share 
the same database.  This is a setup I've seen several times, so I do 
believe its support is necessary.

The only problem with the separate log files was again, losing the 
sequence of events.  It actually made it very difficult to debug 
scenarios, especially when logs were posted to the mailing list and 
extra explanation had to be provided to indicate what happened in what 
order (if it could be determined at all).  If we do go about supporting 
one or two files, I would definately make one file the default for this 
reason.  It also seems to me to be the overall preference of the 
community, but I'd like to hear additional comments.

Unfortunately in the log file it is rather difficult to add metadata, as 
then the file is no longer pure fix which could give it problems with 
some utilities.  This precludes the file from having any sort of 
incoming/outgoing type metadata.

--oren

Brian Erst wrote:

>Oren -
>
>Is that actually a realistic scenario? I'm struggling to come up with a situation where someone would have a FIX acceptor and a FIX initiator talking to each other and sharing the same database log file outside of a badly constructed test environment.
>
>Isn't the log file supposed to show what actually was received, as opposed to some normalized view of the message data? Swapping the compIDs changes the message - if I want to reconstruct the message from the log table, I now have to have program logic that can figure out which direction the message was going and denormalize the data. I can't say that I like that design choice.
>
>Of course, I vastly prefered having separate log files. I wouldn't have minded having the option to have a single log (especially if it was *in addition to* the separate logs), but I now have to modify my workflow (and some scripts) to deal with one log. It's kind of a drag.
>
>- Brian Erst
>Thynk Software, Inc.
>
>----- Original Message ----
>From: Oren Miller <or...@qu...>
>To: Sean Kirkpatrick <sea...@pi...>
>Cc: qui...@li...
>Sent: Wednesday, February 01, 2006 9:32:34 AM
>Subject: Re: [Quickfix-developers] messages_log table entries
>
>QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
>QuickFIX Support: http://www.quickfixengine.org/services.html
>
>Thanks Sean, I checked in a fix for the bug.
>
>We can't really alter the compid's as it would interfere with the 
>counterparties log.  Imagine you have an acceptor running on one 
>machine, and an initiator on another which are connected.  If they are 
>sharing the same database, they will sort of walk all over each other 
>and then things will really get confusing.  So the sessionid fields need 
>to remain constant so they can act as a key.
>
>One option could be to add a direction column which indicates if a 
>message is incoming or outgoing.
>
>--oren
>
>Sean Kirkpatrick wrote:
>
>  
>
>>Hi Oren,
>>
>>I'm testing with 1.11.0 using the PostgreSQL store/log functionality 
>>and had a question.  I think it's great that the incoming/outgoing 
>>logs have been condensed into the single messages_log table, but I was 
>>surprised that the sendercompid / targetcompid column values don't 
>>change to indicate the direction of the message.  I'm guessing these 
>>values are just set based on the sessionID for the configured 
>>session.  Without this functionality the text field has to be grepped 
>>through to determine the direction of the message.  Was this by design?
>>
>>I also found a slight bug in the sql scripts packaged to create the db 
>>tables.  The messages_log_table.sql file still creates the 
>>incoming_log table, rather than the messages_log table.  Changing the 
>>name corrected the issue, but without the change, the Log doesn't 
>>write any of the messages.  Just a head's up.
>>
>>Regards,
>>
>>Sean Kirkpatrick
>>
>>
>>
>>    
>>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>for problems?  Stop!  Download the new AJAX search engine that makes
>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
>_______________________________________________
>Quickfix-developers mailing list
>Qui...@li...
>https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>
>
>
>
>
>  
>

Re: [Quickfix-developers] messages_log table entries

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

Well, the message itself has the CompIDs in the correct place.  We are 
*not* changing the contents of the message at all.  The message column 
always reflects exactly what was sent or received.  We are just talking 
about the database columns which identify the session.  This concept has 
not changed from the previous release.  The incoming and outgoing tables 
would contain the same values in these columns.  The only thing that has 
happened is the tables have been consolidated to retain the sequence of 
events.  All the data within the columns remains exactly the same.

I don't think it is a contrived scenario to have the counterparties 
share the same database.  Many people use FIX for interprocess 
communication within their internal systems.  Those systems often share 
the same database.  This is a setup I've seen several times, so I do 
believe its support is necessary.

The only problem with the separate log files was again, losing the 
sequence of events.  It actually made it very difficult to debug 
scenarios, especially when logs were posted to the mailing list and 
extra explanation had to be provided to indicate what happened in what 
order (if it could be determined at all).  If we do go about supporting 
one or two files, I would definately make one file the default for this 
reason.  It also seems to me to be the overall preference of the 
community, but I'd like to hear additional comments.

Unfortunately in the log file it is rather difficult to add metadata, as 
then the file is no longer pure fix which could give it problems with 
some utilities.  This precludes the file from having any sort of 
incoming/outgoing type metadata.

--oren

Brian Erst wrote:

>Oren -
>
>Is that actually a realistic scenario? I'm struggling to come up with a situation where someone would have a FIX acceptor and a FIX initiator talking to each other and sharing the same database log file outside of a badly constructed test environment.
>
>Isn't the log file supposed to show what actually was received, as opposed to some normalized view of the message data? Swapping the compIDs changes the message - if I want to reconstruct the message from the log table, I now have to have program logic that can figure out which direction the message was going and denormalize the data. I can't say that I like that design choice.
>
>Of course, I vastly prefered having separate log files. I wouldn't have minded having the option to have a single log (especially if it was *in addition to* the separate logs), but I now have to modify my workflow (and some scripts) to deal with one log. It's kind of a drag.
>
>- Brian Erst
>Thynk Software, Inc.
>
>----- Original Message ----
>From: Oren Miller <or...@qu...>
>To: Sean Kirkpatrick <sea...@pi...>
>Cc: qui...@li...
>Sent: Wednesday, February 01, 2006 9:32:34 AM
>Subject: Re: [Quickfix-developers] messages_log table entries
>
>QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
>QuickFIX Support: http://www.quickfixengine.org/services.html
>
>Thanks Sean, I checked in a fix for the bug.
>
>We can't really alter the compid's as it would interfere with the 
>counterparties log.  Imagine you have an acceptor running on one 
>machine, and an initiator on another which are connected.  If they are 
>sharing the same database, they will sort of walk all over each other 
>and then things will really get confusing.  So the sessionid fields need 
>to remain constant so they can act as a key.
>
>One option could be to add a direction column which indicates if a 
>message is incoming or outgoing.
>
>--oren
>
>Sean Kirkpatrick wrote:
>
>  
>
>>Hi Oren,
>>
>>I'm testing with 1.11.0 using the PostgreSQL store/log functionality 
>>and had a question.  I think it's great that the incoming/outgoing 
>>logs have been condensed into the single messages_log table, but I was 
>>surprised that the sendercompid / targetcompid column values don't 
>>change to indicate the direction of the message.  I'm guessing these 
>>values are just set based on the sessionID for the configured 
>>session.  Without this functionality the text field has to be grepped 
>>through to determine the direction of the message.  Was this by design?
>>
>>I also found a slight bug in the sql scripts packaged to create the db 
>>tables.  The messages_log_table.sql file still creates the 
>>incoming_log table, rather than the messages_log table.  Changing the 
>>name corrected the issue, but without the change, the Log doesn't 
>>write any of the messages.  Just a head's up.
>>
>>Regards,
>>
>>Sean Kirkpatrick
>>
>>
>>
>>    
>>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>for problems?  Stop!  Download the new AJAX search engine that makes
>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
>_______________________________________________
>Quickfix-developers mailing list
>Qui...@li...
>https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>
>
>
>
>
>  
>

Re: [Quickfix-developers] messages_log table entries

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

On 2/1/06, Oren Miller <or...@qu...> wrote:

> One option could be to add a direction column which indicates if a
> message is incoming or outgoing.


What about normalizing the data (or is that de-normalizing?) a bit more and
putting a unique ID on the sessions table and using that as a foreign key
for the event_log, message_log and messages tables.  Then the *compid
columns could be per-message, if they are even needed.  The single byte
direction column might be more sensible and save bit of space.

Something like (syntax may not be 100%):

CREATE TABLE sessions (
  id INT UNSIGNED NOT NULL AUTO_INCREMENT,
  beginstring CHAR(8) NOT NULL,
  sendercompid VARCHAR(64) NOT NULL,
  targetcompid VARCHAR(64) NOT NULL,
  session_qualifier VARCHAR(64) NOT NULL,
  creation_time DATETIME NOT NULL,
  incoming_seqnum INT NOT NULL,
  outgoing_seqnum INT NOT NULL,
  PRIMARY KEY (id)
  UNIQUE KEY session_id (beginstring, sendercompid, targetcompid,
session_qualifier)
)

CREATE TABLE message_log (
  id INT UNSIGNED NOT NULL AUTO_INCREMENT,
  session_id INT UNSIGNED NOT NULL,
  direction ENUM ('in', 'out') NOT NULL,
  text BLOB NOT NULL,
  PRIMARY KEY (id),
  FOREIGN KEY (session_id) REFERENCES sessions (id)
)

CREATE TABLE messages (
  session_id INT UNSIGNED NOT NULL,
  msgseqnum INT NOT NULL,
  message BLOB NOT NULL,
  UNIQUE KEY (session_id, msgseqnum),
  FOREIGN KEY (session_id) REFERENCES sessions (id)
)

FYI, I just noticed this code in MySQLLog.cpp:

void MySQLLog::clear()
{ QF_STACK_PUSH(MySQLLog::clear)

  MySQLQuery incoming( "DELETE FROM incoming_log" );
  MySQLQuery outgoing( "DELETE FROM outgoing_log" );
  MySQLQuery event( "DELETE FROM event_log" );
  m_pConnection->execute( incoming );
  m_pConnection->execute( outgoing );
  m_pConnection->execute( event );

  QF_STACK_POP
}

Shouldn't this query be qualifying the delete to match only messages
corresponding to its session?  II don't think Log::clear ever gets called
though.  It seems to be called from SessionState::clear, but I don't see
anything calling that method.

--
Caleb Epstein
caleb dot epstein at gmail dot com

[Quickfix-developers] Getting Fields From Headers

[Mike L. <Mik...@tr...>]

I'm using QuickFix 1.11 with a C# app and I have a couple of questions
concerning Message Class, Header Class and getField() and getHeader().

I have a method in C# that accepts two messages, a QuickFix4.0.Message
and
a QuickFix42.Message.  What I am trying to do is normalize all my
incoming
fix messages to conform to an internal version of 4.2.  I created a
generic method to copy the header and trailer from the 4.0 msg to the
4.2
msg and I am having a world of problems.  Is this possible to do or do I
have to do it at the specific message level (ie: NewOrder, Cancel, etc)?

I've noticed that the only way I can retrieve the fields stated without
it
throwing a FieldNotFound Exception are to use differenct combinations of
getheader and getfield.  Otherwise if I try to use getField on specific
header fields then beginstring, bodylength, and msgtype all throw the
FieldNotFound Exception, if I try to use getHeader().GetField() on
specific header fields then sendercompid and targetcompid throw the
exception.

I've also tried to pull the header out:

QuickFix40.Header originalHeader =3D
(QuickFix40.Header)OriginalMessage.getHeader();
                        QuickFix42.Header newHeader =3D
(QuickFix42.Header)NewMessage.getHeader();


Compiles fine but give me a InvalidCastException: Specified cast is not
valid.  How can I pull these out generically without having to repeat
code
at the specific message method level?  Thanks!

Mike Lee


***************************************************************************=
********

This message and any files transmitted with it are confidential and intende=
d solely for the use of the individual or entity to whom it is addressed. I=
t may contain sensitive and private proprietary or legally privileged infor=
mation. No confidentiality or privilege is waived or lost by any mistransmi=
ssion. If you are not the intended recipient, please immediately delete it =
and all copies of it from your system, destroy any hard copies of it and no=
tify the sender. You must not, directly or indirectly, use, disclose, distr=
ibute, print, or copy any part of this message if you are not the intended =
recipient. Tradition Asiel Securities Inc. and Tradition (North America) In=
c. reserve the right to monitor all e-mail communications through its netwo=
rks. Any views expressed in this message are those of the individual sender=
, except where the message states otherwise and the sender is authorized to=
 state them.

Unless otherwise stated, any pricing information given in this message is i=
ndicative only, is subject to change and does not constitute an offer to de=
al at any price quoted. Any reference to the terms of executed transactions=
 should be treated as preliminary only and subject to our formal written co=
nfirmation. Tradition Asiel Securities Inc. and Tradition (North America) I=
nc. are not responsible for any recommendation, solicitation, offer or agre=
ement or any information about any transaction, customer account or account=
 activity contained in this communication.

This footnote also confirms that this email message has been swept by
Anti-virus detection software for the presence of computer viruses.

***************************************************************************=
********

Re: [Quickfix-developers] messages_log table entries

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

Oren -

Is that actually a realistic scenario? I'm struggling to come up with a situation where someone would have a FIX acceptor and a FIX initiator talking to each other and sharing the same database log file outside of a badly constructed test environment.

Isn't the log file supposed to show what actually was received, as opposed to some normalized view of the message data? Swapping the compIDs changes the message - if I want to reconstruct the message from the log table, I now have to have program logic that can figure out which direction the message was going and denormalize the data. I can't say that I like that design choice.

Of course, I vastly prefered having separate log files. I wouldn't have minded having the option to have a single log (especially if it was *in addition to* the separate logs), but I now have to modify my workflow (and some scripts) to deal with one log. It's kind of a drag.

- Brian Erst
Thynk Software, Inc.

----- Original Message ----
From: Oren Miller <or...@qu...>
To: Sean Kirkpatrick <sea...@pi...>
Cc: qui...@li...
Sent: Wednesday, February 01, 2006 9:32:34 AM
Subject: Re: [Quickfix-developers] messages_log table entries

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

Thanks Sean, I checked in a fix for the bug.

We can't really alter the compid's as it would interfere with the 
counterparties log.  Imagine you have an acceptor running on one 
machine, and an initiator on another which are connected.  If they are 
sharing the same database, they will sort of walk all over each other 
and then things will really get confusing.  So the sessionid fields need 
to remain constant so they can act as a key.

One option could be to add a direction column which indicates if a 
message is incoming or outgoing.

--oren

Sean Kirkpatrick wrote:

> Hi Oren,
>
> I'm testing with 1.11.0 using the PostgreSQL store/log functionality 
> and had a question.  I think it's great that the incoming/outgoing 
> logs have been condensed into the single messages_log table, but I was 
> surprised that the sendercompid / targetcompid column values don't 
> change to indicate the direction of the message.  I'm guessing these 
> values are just set based on the sessionID for the configured 
> session.  Without this functionality the text field has to be grepped 
> through to determine the direction of the message.  Was this by design?
>
> I also found a slight bug in the sql scripts packaged to create the db 
> tables.  The messages_log_table.sql file still creates the 
> incoming_log table, rather than the messages_log table.  Changing the 
> name corrected the issue, but without the change, the Log doesn't 
> write any of the messages.  Just a head's up.
>
> Regards,
>
> Sean Kirkpatrick
>
>
>


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers

[Quickfix-developers] parameter warnings

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

Another minor issue I've come across when compiling with all warnings =
are:

/usr/local/include/quickfix/FieldConvertors.h:360: warning: unused =
parameter `
   bool calculateDays'
/usr/local/include/quickfix/Field.h: In member function
   `FIX::FieldBase::FieldBase(int, const _STL::string&, bool)':
/usr/local/include/quickfix/Field.h:53: warning: unused parameter `bool
   doCalculate'

Basically the parameters are never used within the functions.  To remove =
the warnings, the parameters could either be removed from the funcs, or =
the names just commented out, eg /* doCalculate */.

--Sean

RE: [Quickfix-developers] messages_log table entries

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

Ok.  That's pretty much what I figured.  The direction column would be a =
great addition; the ability to pull either incoming or outgoing messages =
is mainly for troubleshooting production/certification issues and =
operations log viewing.

Thanks!

--Sean

-----Original Message-----
From: Oren Miller [mailto:or...@qu...]
Sent: Wednesday, February 01, 2006 10:33 AM
To: Sean Kirkpatrick
Cc: qui...@li...
Subject: Re: [Quickfix-developers] messages_log table entries


Thanks Sean, I checked in a fix for the bug.

We can't really alter the compid's as it would interfere with the=20
counterparties log.  Imagine you have an acceptor running on one=20
machine, and an initiator on another which are connected.  If they are=20
sharing the same database, they will sort of walk all over each other=20
and then things will really get confusing.  So the sessionid fields need =

to remain constant so they can act as a key.

One option could be to add a direction column which indicates if a=20
message is incoming or outgoing.

--oren

Sean Kirkpatrick wrote:

> Hi Oren,
>
> I'm testing with 1.11.0 using the PostgreSQL store/log functionality=20
> and had a question.  I think it's great that the incoming/outgoing=20
> logs have been condensed into the single messages_log table, but I was =

> surprised that the sendercompid / targetcompid column values don't=20
> change to indicate the direction of the message.  I'm guessing these=20
> values are just set based on the sessionID for the configured=20
> session.  Without this functionality the text field has to be grepped=20
> through to determine the direction of the message.  Was this by =
design?
>
> I also found a slight bug in the sql scripts packaged to create the db =

> tables.  The messages_log_table.sql file still creates the=20
> incoming_log table, rather than the messages_log table.  Changing the=20
> name corrected the issue, but without the change, the Log doesn't=20
> write any of the messages.  Just a head's up.
>
> Regards,
>
> Sean Kirkpatrick
>
>
>

Re: [Quickfix-developers] messages_log table entries

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

Thanks Sean, I checked in a fix for the bug.

We can't really alter the compid's as it would interfere with the 
counterparties log.  Imagine you have an acceptor running on one 
machine, and an initiator on another which are connected.  If they are 
sharing the same database, they will sort of walk all over each other 
and then things will really get confusing.  So the sessionid fields need 
to remain constant so they can act as a key.

One option could be to add a direction column which indicates if a 
message is incoming or outgoing.

--oren

Sean Kirkpatrick wrote:

> Hi Oren,
>
> I'm testing with 1.11.0 using the PostgreSQL store/log functionality 
> and had a question.  I think it's great that the incoming/outgoing 
> logs have been condensed into the single messages_log table, but I was 
> surprised that the sendercompid / targetcompid column values don't 
> change to indicate the direction of the message.  I'm guessing these 
> values are just set based on the sessionID for the configured 
> session.  Without this functionality the text field has to be grepped 
> through to determine the direction of the message.  Was this by design?
>
> I also found a slight bug in the sql scripts packaged to create the db 
> tables.  The messages_log_table.sql file still creates the 
> incoming_log table, rather than the messages_log table.  Changing the 
> name corrected the issue, but without the change, the Log doesn't 
> write any of the messages.  Just a head's up.
>
> Regards,
>
> Sean Kirkpatrick
>
>
>

[Quickfix-developers] messages_log table entries

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

Hi Oren,

I'm testing with 1.11.0 using the PostgreSQL store/log functionality and =
had a question.  I think it's great that the incoming/outgoing logs have =
been condensed into the single messages_log table, but I was surprised =
that the sendercompid / targetcompid column values don't change to =
indicate the direction of the message.  I'm guessing these values are =
just set based on the sessionID for the configured session.  Without =
this functionality the text field has to be grepped through to determine =
the direction of the message.  Was this by design?

I also found a slight bug in the sql scripts packaged to create the db =
tables.  The messages_log_table.sql file still creates the incoming_log =
table, rather than the messages_log table.  Changing the name corrected =
the issue, but without the change, the Log doesn't write any of the =
messages.  Just a head's up.

Regards,

Sean Kirkpatrick

RE: [Quickfix-developers] Capturing Reject MsgType 35=3

[Shepheard, T. (London) <Tob...@ml...>]

Message type 3 (Reject) is an admin-type message, the middle of the
three you list. See, for example,
http://b2bits.com/fixopaedia/fixdic42/index.html for a useful FIX data
dictionary which can help you lookup messages and/or fields by either Id
or name. There are others too, the FIX website has some more links.
=20
Caveat: What follows is from a QFJ perspective but I assume it is the
same model for C#:
=20
QuickFIX will do some automated handling of any admin message, but if
you want to do anything special yourself then you should use the
fromAdmin() callback. There's a brief explanation of the interface at
http://www.quickfixengine.org/quickfix/doc/html/application.html - you
might also want to look at the examples.=20
=20
The reason I suspect its not working for you is that I'm guessing you've
only got a callback for fromApp(), which then calls the crack() method
and, eventually, results in the relevant onMessage() method being called
for any application level messages. If you add a  fromAdmin()  method,
with a call to crack() then you would also get callbacks for the admin
messages. Unlike normal application messages though, you won't get any
error if you don't explicitly handle an onMessage method for an admin
message (as they're typically handled internally).
=20
Hope that helps,
Toby

	-----Original Message-----
	From: qui...@li...
[mailto:qui...@li...] On Behalf Of
Kenny Song
	Sent: 31 January 2006 15:18
	To: qui...@li...
	Subject: [Quickfix-developers] Capturing Reject MsgType 35=3D3
=09
=09
	Hi,
=09
	I'm currently implementing fix 4.2 with quickfix and C#.  I'm
trying to capture reject messages - where field 35=3D3.  I've overriden
the following methods yet none of them seem to capture messages where
field 35=3D3.
=09
	onMessage(QuickFix42.OrderCancelReject message, SessionID
session)
	onMessage(QuickFix42.Reject message, SessionID session)
	onMessage(QuickFix42.ExecutionReport message)
=09
=09
	Does anyone know which method needs to be implemented in order
to capture messages where field 35=3D3?
=09
	Regards
	Kenny
=09
=09
=09

=09
  _____ =20

	Do you Yahoo!?
	With a free 1 GB, there's more in store with Yahoo! Mail.
<http://us.rd.yahoo.com/mail_us/taglines/mailstorage/*http://mail.yahoo.
com/>
--------------------------------------------------------

If you are not an intended recipient of this e-mail, please notify the =
sender, delete it and do not read, act upon, print, disclose, copy, =
retain or redistribute it. Click here for important additional terms =
relating to this e-mail.     http://www.ml.com/email_terms/
--------------------------------------------------------