RE: [Quickfix-developers] Restore messages
Brought to you by:
orenmnero
From: Oren M. <ore...@ya...> - 2003-03-04 15:13:14
|
Well this sounds a little different then what Ming wants. In order to see a complete record of what happened, using the Logging interface (optional interface passed into initiator and acceptor) is a superior choice. The reason is that the store is optimized for the queries it needs, and isn't really good at keeping records. The store only keeps around messages it needs, writes over messages with the same sequence number (so only the newest version of a message exists), and gets cleared out during sequence resets and end of day. The log will keep a complete record of all message transactions and the event log is particularly helpful in showing you when special occurances like resend requests happen. I agree that integrating the incoming and outgoing log files is the right thing to do. --- "Rattinger, John" <Joh...@sa...> wrote: > I also agree! Yes, saving the incoming messages is > not a requirement for the > protocol, but it is a great convenience. There are > several reasons why this > would be a useful feature. > > The most important IMHO is for debugging. When > errors occur with message > processing - such as missed executions, correction, > busts, ..., the user > usually doesn't see them until a break occurs the > next day. At this point a > resend request from the day before is impossible. > Without a complete message > log, it is very difficult to determine who is at > fault and therefore who > should eat the error. I would actually like to take > the logging a step > further and see one integrated log that combined > both incoming and outgoing > messages. This is the only true way to absolutely > determine the sequence of > events. > > Also, I don't like the idea of depending on the > other side to resend the > messages. Even if that engine has been "certified", > it can still have resend > errors and bugs. I know because I have seen it > happen many times from the > top vendors. For this same reason, I never resend > application messages when > the sell side sends a resend request. I have sent > duplicate messages in > response to a resend request and have had them not > recognized as dupes. > > You only have to be burned once to learn that > lesson. > > Having the incoming log is also useful for analyzing > message flow, > latencies, ... > > I agree with Min that is would be nice to have this > as a configurable > option. > > That's my 2 cents on the subject. > John > > ----------------------------------------------------- > John Rattinger > SAC Capital Management Advisors > joh...@sa... > > -----Original Message----- > From: Min Tang [mailto:mi...@op...] > Sent: Tuesday, March 04, 2003 9:03 AM > To: Gene Gorokhovsky; om...@th...; > qui...@li... > Subject: Re: [Quickfix-developers] Restore messages > > > Agree. I think there are many chances for a GUI FIX > trading application to > restore incoming messages. For example, a user > closed then re-open this > application, all recent orders and executions should > be re-loaded. It will > be great helpful if Oren can offer the functionality > to store/recover > incoming message as well (just same as what QuickFix > handles outgoing > messages). For performance consideration, this > shouldn't be mandatory, a > flag in config file can solve the problem. Of course > I can implement this > using outgoing log file, but I do feel this is a > fundamental requirement (I > checked email archive, and at least 3 people > mentioned same thing). > > ----- Original Message ----- > From: "Gene Gorokhovsky" <mus...@ya...> > To: <om...@th...>; "Min Tang" > <mi...@op...>; > <qui...@li...> > Sent: Monday, March 03, 2003 8:27 PM > Subject: Re: [Quickfix-developers] Restore messages > > > > Remember also that you can always ask for the > message > > resend from the session counter-party using FIX. > > > > Gene > > > > --- Oren Miller <ore...@ya...> wrote: > > > > > > You can't. There is no reason to store incoming > > > messages to implement the protocol, so they are > not > > > stored. Doing so would just increase I/O. You > can > > > use the logger interface to store both incoming > and > > > outgoing messages, however you would have to > > > implement something to read them into your > > > application. > > > Min Tang <mi...@op...> wrote:Hello, > We > > > can restore outgoing messages by using FileStore > > > class, but how can I restore incoming messages? > Is > > > there any utility to load XXX.incoming | > > > XXX.outgoing files or I have to write myself? > > > Thanks. > > > > > > > > > --------------------------------- > > > Do you Yahoo!? > > > Yahoo! Tax Center - forms, calculators, tips, > and > > more > > > > > > __________________________________________________ > > Do you Yahoo!? > > Yahoo! Tax Center - forms, calculators, tips, more > > http://taxes.yahoo.com/ > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Etnus, makers of > TotalView, The debugger > for complex code. Debugging C/C++ programs can leave > you feeling lost and > disoriented. TotalView can help you find your way. > Available on major UNIX > and Linux platforms. Try it free. www.etnus.com > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > > > DISCLAIMER: This e-mail message and any attachments > are intended solely for > the use of the individual or entity to which it is > addressed and may contain > information that is confidential or legally > privileged. If you are not the > intended recipient, you are hereby notified that any > dissemination, > distribution, copying or other use of this message > or its attachments is > strictly prohibited. If you have received this > message in error, please > notify the sender immediately and permanently delete > this message and any > attachments. > > > __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ |