ResendRequest never re-sent after re-logon when previous request failed due to responder == null

[RastlinLiu]

Is your feature request related to a problem? Please describe.
After a QuickFIX connection drops and we reconnect, we send a ResendRequest.
If the session disconnects again before the message actually goes out, responder becomes null and the request is not transmitted, but the ResendRange is still updated as if it had been sent.
When the counter-party eventually sends its next message, we should resend the ResendRequest.
Because ResendRange is already marked “sent”, the engine prints:
Already sent ResendRequest FROM: XXXX TO: XXXX. Not sending another.
and skips the request.
As a result we never obtain the missing messages and can never bring the session fully online.
QFJ Version [e.g. 2.1.1]

Describe the solution you'd like
A fix would be to let Session.sendResendRequest examine the boolean returned by sendRaw: if it returns false, the method should not update ResendRange.
I’m not aware of any side-effects this change might introduce, but in our case it appears to work cleanly—ensuring the request is only recorded after it has actually sent, so we neither lose messages nor spam the counter-party.

Describe alternatives you've considered
I know we could set SendRedundantResendRequests=Y to force a resend on every resend request, but both the counter-party owners and I are reluctant to do so for fear of flooding their service with duplicate requests.

Additional context
I originally hit this in QFJ 2.1.1; we now plan to upgrade to 2.3.2.
After scanning the 2.3.2 source I think this particular logic is unchanged.
Please confirm or correct my understanding—thank you.

[chrjohn]

Hi @RastlinLiu , I tried to follow the logic but I am not sure if I understand correctly.

When a session disconnects, method disconnect() is called and the responder is set to NULL. In the finally block of that method, the ResendRange is reset:

quickfixj/quickfixj-core/src/main/java/quickfix/Session.java

Line 2156 in 031152a

state.setResendRange(0, 0);

So with a ResendRange set to (0,0) I am not sure how you can reach the logic that you are referring here:

quickfixj/quickfixj-core/src/main/java/quickfix/Session.java

Line 2504 in 031152a

if (state.isResendRequested()) {

Could you please elaborate. Thank you.

[RastlinLiu]

thanks chrjohn for replying.

I believe the sequence is:

1. The session disconnects first
2. sendResendRequest is triggered afterwards

Although the disconnect finally-block resets ResendRange to (0, 0), the subsequent sendResendRequest logic overwrites that range.
Because the range is now non-zero, the next ResendRequest is regarded as “already sent” and is never issued again.

Below is an excerpt from the FIX event log of our production issue (business-sensitive fields removed).
OM_PROD_SG_XXXX is my service, HS_SG_XXXX is the counter-party; it may help to pinpoint the race condition.

quickfixerror.txt

Hi @RastlinLiu , I tried to follow the logic but I am not sure if I understand correctly.

When a session disconnects, method disconnect() is called and the responder is set to NULL. In the finally block of that method, the ResendRange is reset:

quickfixj/quickfixj-core/src/main/java/quickfix/Session.java

Line 2156 in 031152a

state.setResendRange(0, 0);
So with a ResendRange set to (0,0) I am not sure how you can reach the logic that you are referring here:

quickfixj/quickfixj-core/src/main/java/quickfix/Session.java

Line 2504 in 031152a

if (state.isResendRequested()) {
Could you please elaborate. Thank you.