Backport #384: Always re-resolve SocketAddress on reconnect

[mjkam]

Backport of #384 to the QFJ_2_3_x release branch.

Bug

In all released versions (up to v2.3.2), DNS is not re-resolved after Logout, Connection Reset, or any session-level disconnect. unresolveCurrentSocketAddress() is only called from handleConnectException(), which only runs on TCP connect failures (e.g. Connection Refused). When an established session disconnects, the resolved IP in socketAddresses[] is reused as-is.

This means if the counterparty changes their DNS entry, the client keeps connecting to the old IP indefinitely — especially problematic when the old IP still accepts TCP connections but no longer runs the FIX service (Logon timeout → reconnect → same old IP → infinite loop).

Why there is no performance concern

A concern was raised that re-resolving DNS on every connect could be excessive. However, connect() is only called when shouldReconnect() returns true:

private boolean shouldReconnect() {
    return (ioSession == null || !ioSession.isConnected()) && ...;
}

getNextSocketAddress() is never called while a session is connected. "Every connect" and "only after disconnect" are the same thing. There is no scenario where this change causes unnecessary DNS lookups.

Why this should be backported

• The fix has been on master since May 2021 (4 years) with no reported issues.
• A user reported the same problem in production with AWS in June 2022, and was told no release was planned.
• Cloud environments (AWS ELB/NLB, DNS failover, DR) rely on DNS changes being picked up on reconnect. This is increasingly the norm, not the exception.

[chrjohn]

Does it help to only backport it without a 2.3.x release? 3.0.0 will be released in the near future but no plans on 2.3.x currently...

[mjkam]

Thanks for the context, @chrjohn. Good to know that 3.0.0 is on the horizon -- since it's master-based, the fix from #384 will already be included there.

You raise a fair point about the lack of a planned 2.3.x release. That said, I think there's still some value in having this merged into QFJ_2_3_x:

• Users on 2.3.x who build from source (or maintain internal forks off the branch) would pick it up immediately.
• It serves as a safety net if a 2.3.x patch release ever does become necessary for other reasons.
• For teams running 2.3.x in production, a major version jump to 3.0.0 may require non-trivial testing and validation. Having the fix available at the branch level gives them an option in the interim.

The backport itself is small and low-risk (it's the same change that's been on master since May 2021), so the maintenance burden should be minimal.

Out of curiosity, is there a rough timeline for the 3.0.0 release? That would help folks like me plan the migration path versus applying targeted fixes on 2.3.x in the meantime.

Either way, happy to adjust the PR if needed. Thanks for maintaining the project.

[chrjohn]

Out of curiosity, is there a rough timeline for the 3.0.0 release? That would help folks like me plan the migration path versus applying targeted fixes on 2.3.x in the meantime.

Rough timeline for 3.0.0: in the coming weeks.