Re: [Quickfixj-users] Behaviour of finite vs infinite resend requests in QFJ

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

I think I know why this could be happening: does the broker resend the messages without setting 
PossDup? If yes, then that is the reason for the "too low" disconnection.

I have created a short unit test which highlights this:
https://gist.github.com/chrjohn/30bdcc0940846be18793d0f290c1c2d8

If the resent messages have the PossDup flag, the test completes successful. Otherwise it is failing 
as you described.
So IMHO your counterparty is misbehaving.

Cheers,
Chris.



On 13.11.20 02:20, Christoph John via Quickfixj-users wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
>
> Hi,
>
> actually I have never seen this behaviour where the connection is dropped because the queued 
> messages are processed (and then are too low a sequence number).
> I quickly checked our log files but could not find an occurrence where more than one app message 
> is resent.
> I'd like to write a unit test to reproduce this behaviour but currently am a little too busy. :-/
>
> Cheers,
> Chris.
>
> On 10.11.20 12:09, Philip Whitehouse wrote:
>> QuickFIX/J Documentation:http://www.quickfixj.org/documentation/
>> QuickFIX/J Support:http://www.quickfixj.org/support/
>>
>>
>>
>> Hi all,
>>
>> In the FIX spec (FIX Session Layer Technical Specification) in "4.8.2 Request retransmission of 
>> messages" we see several scenarios.
>>
>> QFJ seems to operate based on a hybrid of the two which has a problem in certain scenarios.
>>
>> We enqueue messages received (per the second approach). But we also send an infinite resend request.
>>
>> Thus in the scenario provided if we receive 3,4,5 we will enqueue them. Then we will re-request 2 
>> -> 0.
>> A compliant broker then sends, 2,3,4,5 per the first approach.
>> When we get 2, we process it then de-queue 3,4,5 and process them. Then when we process 3,4,5 
>> from the broker we complain (in the form of a disconnect).
>>
>> Has anyone else seen this behaviour.
>>
>> My view is:
>>
>>  1. If we send an infinite resend request we should discard queued messages
>>  2. If we send a finite resend request we should keep enqueuing messages
>>
>> I'm unclear how "ClosedResendInterval" should affect this - or is "ClosedResendInterval" 
>> essentially "follow the spec" (contrary to the docs).
>>
>> Best regards,
>>
>> Philip Whitehouse
>>
>>
>> _______________________________________________
>> 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
>
>
> _______________________________________________
> 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