Thread: [Quickfix-developers] Message storage and retrieval

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Hi

Starting the debate of earlier threads again...

IMHO a client app could either try to keep the state of the world (SOW)
itself of delegate it to something else which then uses different
methods for dispersing this info.  A client app could go to a db to get
known orders and status on startup, connect to a pub/sub system and
request the current SOW or whatever.

A server, however, specially something like an order manager must keep
track of its orders EVEN through a core !!!  As Oren mentioned in some
earlier thread, this presents a problem.  Server which handle large
order flow will have a huge FIX traffic whose latency needs to be kept
to a minimum.  Writing orders to a db or whatever is basically out of
the quesion because of the IO time involved.  Since QF does have the
logs stored if the file system one would imagine that re-loading the
order server to the state prior to a core is just a matter of replaying
the messages and rebuiding the order collection.

This however, is a server problem, not a qf problem.  I would vote for
writing a small library for reading and even better, replaying these
messages.  For instance we could create a MessageReplayApplication which

subclasses Application.  This classes' thread would read the inbound log

file and invoke fromApp callbacks.  Any messages sent by this app would
be ignored!!!!  This would allow a server to rebuild its state.  When
done, the main class deletes this playback object and start the real
one....  Just a thought anyways.

The point is that for some apps we DO need to have not just message
recovery but state recovery as well...

David

--
NOTICE: If received in error, please destroy and notify sender.  Sender
does not waive confidentiality or privilege, and use is prohibited.

Thread: [Quickfix-developers] Message storage and retrieval

quickfix-developers