apache/shardingsphere · error · GetResultTimeoutException
Get result timeout
Error message
Get result timeout
What it means
ResponseFuture.waitResponseResult blocks on a CountDownLatch for at most timeoutMillis. If the server response does not arrive in time, the future is removed from the connection context map and GetResultTimeoutException is thrown, so the caller knows the request is still outstanding and will never be completed by a late response.
Source
Thrown at kernel/data-pipeline/scenario/cdc/client/src/main/java/org/apache/shardingsphere/data/pipeline/cdc/client/util/ResponseFuture.java:71
private String errorMessage;
private Object result;
/**
* Wait response result.
*
* @param timeoutMillis timeout milliseconds
* @param connectionContext connection context
* @return response result
* @throws GetResultTimeoutException get result timeout
* @throws ServerResultException server result exception
*/
@SneakyThrows(InterruptedException.class)
public Object waitResponseResult(final long timeoutMillis, final ClientConnectionContext connectionContext) {
if (!countDownLatch.await(timeoutMillis, TimeUnit.MILLISECONDS)) {
connectionContext.getResponseFutureMap().remove(requestId);
throw new GetResultTimeoutException("Get result timeout");
}
connectionContext.getResponseFutureMap().remove(requestId);
if (!Strings.isNullOrEmpty(errorMessage)) {
throw new ServerResultException(String.format("Get %s response failed, code:%s, reason: %s", requestType.name(), errorCode, errorMessage));
}
return result;
}
/**
* Count down.
*/
public void countDown() {
countDownLatch.countDown();
}
}
View on GitHub (pinned to e952770a21)
Solutions
- Increase the client response timeout configuration passed to waitResponseResult.
- Check proxy health, GC logs, and CDC job status; a wedged job on the server side delays responses.
- Verify network connectivity and idle-timeout settings (firewall/LB) between the CDC client and proxy port.
- Retry the request once connectivity is restored; the failed future is already removed from the map so a retry creates a fresh requestId.
Defensive patterns
Strategy: retry
Try / catch
try {
result = future.waitResponseResult(timeoutMillis, ctx);
} catch (final GetResultTimeoutException ex) {
// future already removed from context map; safe to retry with a new request
result = retryOnce(requestBuilder.build());
} Prevention
- Size the client timeout for worst-case server latency (large initial transfers).
- Monitor proxy health/GC before running large CDC operations.
- Keep client-server connections alive through firewalls (TCP keepalive).
When it happens
Trigger: Any blocking CDC client call (start/stop subscription, DDL fetch, etc.) whose response does not arrive within the configured timeout: network partition between client and proxy, proxy busy or restarted, request dropped, or the response arriving after the latch window expired.
Common situations: Aggressive client timeout settings; proxy GC pauses or heavy load during large initial data transfers; firewalls dropping idle connections; proxy restarted while the client was waiting.
Understand the failure class
- Timeouts: ETIMEDOUT, deadlines, and hung requests — what actually expires when a request times out.
Related errors
- not support unpack the type %s
- Get %s response failed, code:%s, reason: %s
- Can not support type `%s`.
- MySQL BLOB type meta in binlog should be range 1 to 4, but a
- MySQL JSON type meta in binlog should be range 1 to 4, but a
AI-assisted analysis of apache/shardingsphere@e952770a21 (2026-08-14).
Data as JSON: /api/errors/21d7c7daf1c5140e.
Report an issue: GitHub.