Re: [Quickfix-developers] messages_log table entries
Brought to you by:
orenmnero
|
From: Oren M. <or...@qu...> - 2006-02-01 16:49:20
|
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 > > > > > > > |