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.