{{Quickfixn}} Recovery Strategies

Ian Clements ian.clements at investmentsoftwareltd.com
Fri Sep 25 12:59:41 PDT 2015


Thanks Mike hadn't thought of that will give it a go much more elegant than my solution.   Have been seeing a lot of aggressive seq resets from our provider but probably more down to my ignorance of fix protocol!

------ Original message------

From: Mike Gatny

Date: Fri, 25 Sep 2015 18:28

To: Mailing list for QuickFIX/n;

Subject:Re: {{Quickfixn}} Recovery Strategies



On Fri, Sep 25, 2015 at 11:50 AM, Ian Clements <ian.clements at investmentsoftwareltd.com<mailto:ian.clements at investmentsoftwareltd.com>> wrote:
If my service crashes (Server fails or unhandled exception) then my queue which is in memory gets lost.  When I restore my service I need to load these messages back into the queue.

One slick way to do this is to leverage FIX protocol resends.  If you make the msg seq num part of the data you record when a message is successfully processed, when a crash occurs you can 1) note the last processed seq num, 2) edit the qf/n .seqnums file accordingly, 3) restart your app.  The other side will resend what you haven't processed.

If the crash happened during the current FIX session I was tracking which SeqNum I had reached in my DB so I figured in the OnCreate method I could just retrieve the messages from the message store but it is returning nothing which I don’t understand as the store files are still populated.

The message store is for messages you sent, not messages you received.  They are stored in case you need to honor a resend request from the other side.  And hence the method mentioned above.

If I have done a LogOut (Which clears the store files as the collection resets) and I am still processing messages I persist the messages currently on the queue to a file which I can then restore – this approach seems to work.

Yep, you have to go to disk one way or another -- whether it is writing to your own ad-hoc file, re-reading the qf messages log, writing to a durable msg queue, writing to a db.  As long as you can avoid blocking too long during FromApp/OnMessage, any of these can work.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.quickfixn.com/pipermail/quickfixn-quickfixn.com/attachments/20150925/1a20d242/attachment-0002.htm>


More information about the Quickfixn mailing list