Re: [Quickfix-developers] Waiting for Resend to finish? Revisited...

[Oren M. <or...@qu...>]

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
>