Re: [Quickfixj-users] Issue related to message recovery

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

Hi Ankit,

The NewSeqNo on the incoming SequenceReset sets the incoming seqnum from to 62002. So between 60489 and 62002 the counterparty did not send any application messages, just session messages (e.g. heartbeats). Can you confirm this from the logs?
Actually QFJ should realise that setting the seqnum to 62002 should satsify the resend request. Your QFJ version seems to be relatively current, so it *might* be a bug. I don’t know how many users are using the chunked resend requests, so this might be a corner case that no-one else ran into.
Can you provide the related event and message logs? But better send them privately, NOT to the list.

Cheers
Chris

--
Christoph John
Software Engineering

[cid:image001.png@01DC946B.039F5F20]
Foconis Trading GmbH
Oppenhoffallee 103
52066 Aachen

Web: https://foconis.com<https://foconis.com/>
E-Mail: chr...@fo...<mailto:chr...@fo...>
Tel.: +49 241 557080 28 / Zentrale-0

Geschäftsführer: Peter Kretzmann, George Macdonald
Amtsgericht Hamburg: HRB 46346 | USt-IDNr.: DE118680003
Unsere Hinweise zum Datenschutz sind hier zu entnehmen (Artikel 13, 14 und 21 EU-DSGVO):
https://group.foconis.com/datenschutz

From: Ankit Mehta <ank...@gm...>
Sent: 31 January 2026 17:04
To: qui...@li...
Subject: Re: [Quickfixj-users] Issue related to message recovery

You don't often get email from ank...@gm...<mailto:ank...@gm...>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
Thanks Chris for coming back.

Analysed further by looking the INCOMING and EVENTS logs and this is what I think happened, could you please check and confirm if this is correct understanding-

1. Gap Detected: Expected 57989, received 61989
2. Resend Requests Sent: 57989 -> 60488 and then 60489 -> 61989 (since they are chunked)
3. Live/New messages arrived that gets queued up: 61993/61994-61995….
4. Sequence Reset received from their end with tag 34=60489 and tag 36=62002

And this in my understanding caused the queued message from being processed, since they asked us to reset to 62002.
The new seq no tag on the sequence reset message here was the culprit?

Let me know your thoughts on this.

Thanks,
Ankit


On Sat, 31 Jan 2026 at 9:11 PM, Christoph John via Quickfixj-users <qui...@li...<mailto:qui...@li...>> wrote:
Hi


Queued messages are not processed until the resend request has been satisfied. E.g. if you are waiting for a resend of messages up to seqnum 1000, all seqnums lower than 1000 are not processed until message seqnum 1000 has been received.

Cheers
Chris


--

Christoph John

Software Engineering



Foconis Trading GmbH

Oppenhoffallee 103<https://www.google.com/maps/search/Oppenhoffallee+103+%0D%0A+%0D%0A+52066+Aachen?entry=gmail&source=g>

52066 Aachen<https://www.google.com/maps/search/Oppenhoffallee+103+%0D%0A+%0D%0A+52066+Aachen?entry=gmail&source=g>



Web: https://foconis.com<https://foconis.com/>

E-Mail: chr...@fo...<mailto:chr...@fo...>

Tel.: +49 241 557080 28 / Zentrale-0



Geschäftsführer: Peter Kretzmann, George Macdonald

Amtsgericht Hamburg: HRB 46346 | USt-IDNr.: DE118680003
Unsere Hinweise zum Datenschutz sind hier zu entnehmen (Artikel 13, 14 und 21 EU-DSGVO):

https://group.foconis.com/datenschutz



________________________________
From: Ankit Mehta <ank...@gm...<mailto:ank...@gm...>>
Sent: 31 January 2026 09:25
To: qui...@li...<mailto:qui...@li...> <qui...@li...<mailto:qui...@li...>>
Subject: [Quickfixj-users] Issue related to message recovery

You don't often get email from ank...@gm...<mailto:ank...@gm...>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
hi team,

We had an issue recently wherein there was a disconnection on the acceptor side.
The initiator rightly failed over to the second host and sent a resend request, which was fulfilled by the server as well.
The instability persisted and we noticed multiple resend requests were sent in between.
What we noticed though, during the time the application was catering to processing re-sent messages, when new messages were coming in at the same time they were getting queued up.

We saw lines like below in the events logs:

MsgSeqNum too high expecting <> but received <> ....
Enqueued at pos: <num>

In ideal scenarios, which I can see for certain messages in the beginning, we see log like this:
Processing queued message: <num>

But we do not see this happening for the majority of these new trade messages causing the messages to be eventually missed.

We are on quickfix all version 2.3.0.
Would anyone have seen such an issue and can opine what could have happened?

Regards,
Ankit