Re: [Quickfixj-users] Quickfixj enqueuing logon and not sure when a resend request is satisfied.

[Robert N. <rob...@gm...>]

So it seems that Quickfixj is suppose to consider the resend request satisfied when it processes a message that’s higher than the end range (16=0 but it’s recorded the range)  of the resend request.

On this occasion it did that but didn’t consider the resend request satisfied.

> On Sep 21, 2020, at 9:00 AM, Robert Nicholson <rob...@gm...> wrote:
> 
> I have an older quickfixj  application that seems to repeatedly have more issues with one vendors traffic than another.
> 
> This vendor has a custom implementation of their FIX engine and I’m wondering if the problems that result from that are due to quickfixj or their implementation.
> 
> In the latest episode I have an example where
> 
> I logon
> 
> their logon was queued because it was received out of order after a disconnect.
> 
> our end has sent a resend request
> 
> their end has sent a resend request
> 
> then they begin to satisfy the resend request I made with all those message that have posdup = Y 
> 
> at the end they have began sending messages with a 34 that’s 1 more than the 34 they used with their resend request earlier.
> 
> There is no sequence reset from them at all.
> 
> At the point quickfixj still doesn’t consider the resend request satisfied and is continuing to enqueue every subsequent message.
> 
> The version used is older 1.52 with custom patches including the recursive resend request handling to avoid stack overflow.
> 
> Q. What does quickfixj generally expect to see before it considers a resend request satisfied?