Re: [Quickfix-developers] Waiting for Resend to finish? Revisited...
Brought to you by:
orenmnero
|
From: Oren M. <or...@qu...> - 2006-03-22 09:24:07
|
You could check the sequence number of the outgoing message against the next expected outgoing sequence number. --oren On Mar 21, 2006, at 8:07 AM, Edde wrote: > Hi Guys, > > I appologize to bother you with this once again... > > >Oren wrote: > >So I suggest that you clear the expected sequence number *before* > starting the application. > >That way QuickFIX will allways request a retransmission from 1 > thru infinity, and since QuickFIX > >requested the retransmissions it will know what to do with them. > > I've now rewritten my application according to this design and it > seems to work fine. However, I would still like to know if there is > a way to know when QuickFIX has resent all messages? > > >Joerg wrote: > >BTW, a TestRequest with a unique has to be answered by a Heartbeat > with this unique id. > >If you get this specific heartbeat, you know that the other side > must have processed all > >messages preceding this TestRequest. Of course, this does not > prevent further resend > >processing at any later point of time. > > I've tried this approach but unfortunately our counterparty doesn't > quite live up the FIX specification in this regard. It works great > most of the time but every now and then our counterparty "forget" > to answer my TestRequest with the corresponding heartbeat. > Is there another way to do this? I've noticed that QuickFIX logs > the following event when the Resend has finished: "ResendRequest > for messages FROM: 1 TO: XXXX has been satisfied.". Is there a way > for me to get this message on an application level? > Another solution I was thinking off was to check for the first > message where the PossDupFlag isn't set and then assume that the > Resend is finished but I'm not sure this is a fail proof solution. > > Any comments or suggestions will be deeply appreciated. > Thanks, > /Eddie > |