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

[Joerg T. <Joe...@ma...>]

Hi Staffan,

> I've recently been working a bit on a FIX acceptor for order handling
> using QuickFIX.  I'm using quickfixj, and have managed to get the
> connection up and the initiators seem happy with the setup.  That is,
> they can send orders and execution reports are sent back from my accept=
or.
>=20
> This is all still in the testing stage, however, and I was wondering
> about what to do whenever a connection is reconnected after a
> disconnect, and how to handle a restart of the server.  How much of
> gap filling and resending is handled by the quickfix engine itself?
> What do I have to do?  I realize the answer might be too complex for a
> short mail reply, but I've not been able to find much documentation
> either.  Any pointers?

All the session level gap fill/resend processing is done for you by the Q=
uickFIX engine.

But there are some fine points where you can influence the process:

Look at this scenario: You are sending an order to the exchange, but the =
connection breaks=20
down. QuickFIX takes care of your NewOrderSingle and will resend it as so=
on as the=20
connection is up again and the other side requested it as part of a Resen=
dRequest.

BUT: This may take a while and your order would be sent 10 mins too late.

Before sending the NewOrderSingle again, QF will pass it through the toAp=
p() callback.
Here you can check for the PossDup flag and if it is true, you can retrie=
ve the=20
OrigSendingTime, at which the order has been sent the first time. If the =
difference=20
between SendingTime (now) and OrigSendingTime is too large, you can throw=
 a DoNotSend=20
exception and QF will gap fill the message instead of sending the outdate=
d order.

> 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 tha=
t the message=20
arrives at the client end after a crash or disconnection. So you just hav=
e to record which=20
of your order status related message you have already sent to QF and star=
t at this point.

If you are unsure whether you have already sent some application level me=
ssages to the=20
other side, you may flag messages with the PossResend flag which indicate=
s that the same=20
business information (e.g. a Fill) may have sent before to the other side=
 in another=20
message (different MsgSeqNo). Please do not confuse this with PossDup (it=
 relates to the=20
_same_ MsgSeqNo and is handled by the FIX engine).

Cheers, J=F6rg

--=20
Joerg Thoennes
                                http://macd.com
Tel.: +49 (0)241 44597-24      Macdonald Associates GmbH
Fax : +49 (0)241 44597-10      Lothringer Str. 52, D-52070 Aachen