conductor-oss/conductor · critical · RuntimeException
Timeout while connecting to <addresses>
Error message
Timeout while connecting to <addresses>
What it means
createConnection caught a TimeoutException from factory.newConnection and retrySettings is null, so it propagates immediately. TimeoutException means the AMQP handshake did not complete within the connection timeout configured on the factory (set via properties.getConnectionTimeoutInMilliSecs).
Source
Thrown at amqp/src/main/java/com/netflix/conductor/contribs/queue/amqp/AMQPConnection.java:154
final String error =
"Retries completed. IO error while connecting to "
+ Arrays.stream(addresses)
.map(address -> address.toString())
.collect(Collectors.joining(","));
LOGGER.error(error, e);
throw new RuntimeException(error, e);
}
retryIndex++;
} catch (final TimeoutException e) {
AMQPRetryPattern retry = retrySettings;
if (retry == null) {
final String error =
"Timeout while connecting to "
+ Arrays.stream(addresses)
.map(address -> address.toString())
.collect(Collectors.joining(","));
LOGGER.error(error, e);
throw new RuntimeException(error, e);
}
try {
retry.continueOrPropogate(e, retryIndex);
} catch (Exception ex) {
final String error =
"Retries completed. Timeout while connecting to "
+ Arrays.stream(addresses)
.map(address -> address.toString())
.collect(Collectors.joining(","));
LOGGER.error(error, e);
throw new RuntimeException(error, e);
}
retryIndex++;
}
}
}
public Channel getOrCreateChannel(ConnectionType connectionType, String queueOrExchangeName)View on GitHub (pinned to cf7c3e4a8a)
Solutions
- Increase the connection timeout via AMQPEventQueueProperties.connectionTimeoutInMilliSecs (it is passed to factory.setConnectionTimeout).
- Measure round-trip latency to the broker and confirm the timeout exceeds it with headroom.
- Check broker CPU/load during the connection attempt.
- Wire an AMQPRetryPattern so transient timeouts are retried instead of failing fast.
Example fix
# before: handshake times out under latency conductor.amqp.connectionTimeoutInMilliSecs=2000 # after: give the handshake room conductor.amqp.connectionTimeoutInMilliSecs=10000
Defensive patterns
Strategy: retry
Validate before calling
// Sanity-check the configured timeout against measured latency before building
long rtt = measureRoundTrip(host, port);
if (rtt >= properties.getConnectionTimeoutInMilliSecs()) {
throw new IllegalStateException("connection timeout "
+ properties.getConnectionTimeoutInMilliSecs()
+ "ms is below measured RTT " + rtt + "ms");
} Try / catch
try {
amqpConnection.getOrCreateChannel(type, name);
} catch (RuntimeException e) {
if (e.getCause() instanceof java.util.concurrent.TimeoutException) {
// handshake timed out; raise the timeout or retry upstream
}
throw e;
} Prevention
- Set connectionTimeoutInMilliSecs comfortably above measured broker RTT.
- Wire an AMQPRetryPattern so a one-off handshake timeout is retried.
- Investigate sustained handshake latency as a broker-load or network problem.
When it happens
Trigger: getOrCreateChannel triggers createConnection; the broker is reachable on the TCP socket but the AMQP handshake does not complete in time; retrySettings is null so the no-retry branch throws.
Common situations: Broker overloaded and slow to handshake; high network latency exceeding the connection timeout; a stateful firewall that allows the SYN but drops subsequent handshake packets; connection timeout configured too low.
Understand the failure class
- Timeouts: ETIMEDOUT, deadlines, and hung requests — what actually expires when a request times out.
Related errors
- Failed to open connection
- IO error while connecting to <addresses>
- Retries completed. Timeout while connecting to <addresses>
- Retries completed. IO error while connecting to <addresses>
- Anthropic Messages API call failed: {message}
AI-assisted analysis of conductor-oss/conductor@cf7c3e4a8a (2026-08-14).
Data as JSON: /api/errors/364ec3776969bfa8.
Report an issue: GitHub.