Re: [Quickfix-users] Some questions about restarting a quickfix server

[Staffan U. <sta...@mu...>]

Hello again, 

Thanks Joerg for the info!

Is there any other source for documentation except the main web site
and the souce code?  I find that many minor points (for example,
is an outgoing FIX message guaranteed to be written to the message
store before it is sent to the client?  When are incoming messages
written to the message store?) are hard to find answers to...

> > When the server is restarted, maybe after a crash, one way to find out
> > if there are any orders whose status is not known by the client is to
> > read the message log.  Is there any way to do that while using the
> > quickfix engine's message parsing functions?
> 
> If the QF sendToTarget() method returns, the QF engine will make sure
> that the message arrives at the client end after a crash or
> disconnection. So you just have to record which of your order status
> related message you have already sent to QF and start at this point.
> 
> If you are unsure whether you have already sent some application level
> messages to the other side, you may flag messages with the PossResend
> flag which indicates that the same business information (e.g. a Fill)
> may have sent before to the other side in another message (different
> MsgSeqNo). Please do not confuse this with PossDup (it relates to the
> _same_ MsgSeqNo and is handled by the FIX engine).

Yes, I realize I could have my own database to record whatever
information has been sent to the counterparties I'm communicating
with.

I was thinking along these lines, however: I'm writing a FIX gateway
for a proprietary exchange API.  Since the proprietary API allows
me to chose the order id, I could let that order id be a
string composed of the FIX client's compid and the FIX client order
id.  Then, at application start, I could read the FIX log to find all
orders that are still active as far as the FIX client knows.  Since
the client order ids are enough to identify the orders at the
exchange, I could just query their state and send out execution
reports with their current status, if different from what has already
been sent.  (Or, just send out all information including trades for
these orders, with the PossResend flag set.)

Anyway, then I have to parse the FIX message log...  Not very hard to
do by hand since there are only a couple of messages of interest, but
it would of course be nice to be able to use all of the type safe
functions in the QuickFIX api...

Staffan