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

[Christoph J. <chr...@ma...>]

When I compare the description in the bug ticket to your description it looks like the same issue to 
me, especially considering the following:
* Logon from counterparty has higher seqnum than expected and is queued
* the order of resend requests (first your side, then theirs)
* In the bug ticket the resend request from the counterparty has seqnum 7 which later incorrectly is 
the expected seqnum although it should be 8. Hence all incoming messages are queued. This matches 
your statement of "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.".

But eventually a message log would probably be best to check if it is the same issue.

What do you think?

Cheers,
Chris.


On 22.09.20 03:05, Robert Nicholson wrote:
> In my example I’m not the one satisfying the resend request. I’m the initiator.
>
> I’m the one who sent it because of the detected gap.
>
> Do you still think that bug is related to my scenario?
>
>> On Sep 21, 2020, at 6:04 PM, Christoph John <chr...@ma... 
>> <mailto:chr...@ma...>> wrote:
>>
>> Hi,
>>
>> sounds like this bug to me: https://www.quickfixj.org/jira/browse/QFJ-673
>> This is fixed in 1.6.0.
>>
>> Cheers,
>> Chris.
>>
>> On 21.09.20 19:30, Robert Nicholson wrote:
>>> QuickFIX/J Documentation:http://www.quickfixj.org/documentation/
>>> QuickFIX/J Support:http://www.quickfixj.org/support/
>>>
>>>
>>> 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?
>>> _______________________________________________
>>> Quickfixj-users mailing list
>>> Qui...@li...
>>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>
>> -- 
>> Christoph John
>> Software Engineering
>> T +49 241 557080-28
>> chr...@ma...
>>
>> MACD GmbH
>> Oppenhoffallee 103
>> 52066 Aachen, Germany
>> www.macd.com
>>
>> Amtsgericht Aachen: HRB 8151
>> Ust.-Id: DE 813021663
>> Geschäftsführer: George Macdonald
>

-- 
Christoph John
Software Engineering
T +49 241 557080-28
chr...@ma...

MACD GmbH
Oppenhoffallee 103
52066 Aachen, Germany
www.macd.com

Amtsgericht Aachen: HRB 8151
Ust.-Id: DE 813021663
Geschäftsführer: George Macdonald