Fix reconnection hang on HTTP proxy connect failures and stalled handshakes

[rishabhagl]

Summary

Fixes #1274 — reconnection permanently stalls when connecting through an HTTP proxy if the proxy connect fails with an exception, or if the CONNECT handshake stalls without resolving the ConnectFuture at all.

Problem

IoSessionInitiator.pollConnectFuture() only checked future.getSession() != null. If the future instead completed exceptionally (e.g. proxy returns 407, or the CONNECT is rejected), the code fell through into the "still pending" branch, which just logged a message and never cleared connectFuture or called handleConnectException(). Since shouldReconnect() requires connectFuture == null, the initiator got stuck and never retried.

Separately, a stalled proxy handshake (no session, no exception — MINA's proxy filter wedged mid-negotiation) had no timeout at all and could hang indefinitely.

Fix

• pollConnectFuture() now explicitly checks future.getException() and routes it through handleConnectException(), clearing connectFuture immediately.
• Added a connectTimeoutMillis-based watchdog: if a connect attempt has been pending longer than this, cancelAndResetPendingConnectAttempt() is invoked to:
  • force-close any half-open IoSession and cancel the future,
  • if ioConnector instanceof ProxyConnector, cancel the proxy connector's internal connect future and recreate the connector via setupIoConnector(),
  • reset lastConnectTime/lastReconnectAttemptTime to the current time so the next scheduled reconnect doesn't fire immediately (previously pendingMillis would already exceed ReconnectInterval, causing a premature/rapid retry loop) or never (if left unset).

Testing

Added IoSessionInitiatorConnectTaskTest, which targets the private IoSessionInitiator.ConnectTask polling state machine via reflection (the fix lives inside this private class, so tests construct ConnectTask directly and invoke pollConnectFuture(), cancelAndResetPendingConnectAttempt(), and handleConnectException() reflectively).

Coverage includes:

• Pending connect exceeds connectTimeoutMillis — future is cancelled, timeout events are logged, onConnectException fires, connectFuture clears, failure count increments once, and both timers reset so shouldReconnect() correctly waits out the full ReconnectInterval.
• Pending connect within timeout — future is left untouched, no timeout logs/callbacks fire, failure count stays at zero.
• Future completes with a real exception (not a timeout) — routes through the existing exception path, not the new watchdog: no explicit cancel, correct error logged, future cleared, failure count incremented.
• Successful connect — session stored, future cleared, failure count and address index reset, lastConnectTime updated.
• Proxy connect timeout (via a TestProxyConnector stub) — confirms the pending future is cancelled, cancelConnectFuture() is called, and the connector instance is recreated (not reused).
• cancelAndResetPendingConnectAttempt — closes a half-open session before cancelling the future and separately confirms proxy-connector cancellation/recreation in isolation.
• handleConnectException — unwraps nested causes, increments failure count, clears the future, and notifies the state listener.

All existing tests in quickfixj-core pass locally with this change.

Related

• Fixes Reconnection hangs indefinitely when ConnectFuture fails or stalls through an HTTP proxy (IoSessionInitiator) #1274
• Related to Connecting over an authenticating HTTP proxy fails #295, QFJ-868, QFJ-895

[chrjohn]

Why is this only done on a ProxyConnector? I assume because it has some internal state that needs to be handled differently? Maybe add some explanation?
Edit: I'm still thinking about if this could conflict with the dispose-logic.

[rishabhagl]

I got this exception when reused IoConnector for proxy.
java.lang.IllegalStateException: handler cannot be set while the service is active.
at org.apache.mina.core.service.AbstractIoService.setHandler(...)
at org.apache.mina.proxy.ProxyConnector.connect0(...)

This exception does not occure when reusing the IoConnector in non-proxy connection timeout, where the server does not reply TCP SYN.
by explanation, you mean adding code comment?