apache/seatunnel · warning
Edge socket receiver executor did not terminate within timeo
Error message
Edge socket receiver executor did not terminate within timeout
What it means
Warned by stopReceiverLoop() when the receiver executor does not terminate within the 3-second awaitTermination window after shutdownNow(). The stop() sequence continues (executor is nulled) but the underlying thread may still be briefly running, which can delay resource release or leave the port bound momentarily.
Source
Thrown at seatunnel-connectors-v2/connector-edge-socket/src/main/java/org/apache/seatunnel/connectors/seatunnel/edgesocket/source/EdgeSocketIngressServer.java:255
log.error(
"Edge socket receiver thread fatal exception",
receiverException);
fatalReceiverException = receiverException;
throw receiverException;
}
});
}
private void stopReceiverLoop() {
if (receiverFuture != null) {
receiverFuture.cancel(true);
receiverFuture = null;
}
if (receiverExecutor != null) {
receiverExecutor.shutdownNow();
try {
if (!receiverExecutor.awaitTermination(3, TimeUnit.SECONDS)) {
log.warn("Edge socket receiver executor did not terminate within timeout");
}
} catch (InterruptedException interruptedException) {
Thread.currentThread().interrupt();
} finally {
receiverExecutor = null;
}
}
}
private boolean isInterruptedDuringRetryWait() {
try {
TimeUnit.MILLISECONDS.sleep(config.getReconnectIntervalMs());
return false;
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
return true;
}
}View on GitHub (pinned to cf67b549a7)
Solutions
- Reduce acceptTimeoutMs / socket timeouts so the loop notices interrupts promptly.
- Increase the awaitTermination window if your shutdown budget allows, or poll isReceiverAlive() after stop().
- Ensure collector connections are closed before stopping the server during graceful shutdown.
- If it recurs, investigate the receiver thread's blocking point with a thread dump (jstack).
Example fix
// before
if (!receiverExecutor.awaitTermination(3, TimeUnit.SECONDS)) { log.warn(...); }
// after
receiverExecutor.awaitTermination(3, TimeUnit.SECONDS);
if (!receiverExecutor.isTerminated()) { log.warn(...); receiverExecutor.awaitTermination(10, TimeUnit.SECONDS); } Defensive patterns
Strategy: try-catch
Validate before calling
// before stop()
if (server.isReceiverAlive()) { log.info("receiver still alive; stopping with active collector connections may delay termination"); } Try / catch
try { server.stop(); } catch (RuntimeException e) { log.warn("stop did not fully terminate receiver: {}", e.getMessage()); } Prevention
- Keep acceptTimeoutMs moderate so accept() wakes up during shutdown
- Close collector connections before stopping the server
- Confirm termination with a liveness check after stop()
- Capture a thread dump if the warning repeats to find the blocking call
When it happens
Trigger: stop() called while the receive loop is blocked in an operation that ignores interrupts and exceeds 3 seconds — e.g. a long accept() with a large soTimeout, a slow collector read, or a wedged write.
Common situations: Shutdown with an active collector streaming data, accept timeout configured very high (acceptTimeoutMs), container freeze/pause during shutdown, thread blocked on a stuck socket write.
Understand the failure class
Background: Request timed out: what client-side request timeouts mean across libraries (Request timed out, TIMED_OUT, APITimeoutError) — this error's family across 39 libraries.
- Timeouts: ETIMEDOUT, deadlines, and hung requests — what actually expires when a request times out.
Related errors
- The split fetcher manager has closed.
- Python source was closed while writing python.script.config
- WALDisruptor close timeout error
- Failed to close the source reader in {} ms. There are still
- Continuous discovery scheduler does not terminate in 5 secon
AI-assisted analysis of apache/seatunnel@cf67b549a7 (2026-09-10).
Data as JSON: /api/errors/0909dca958f31c77.
Report an issue: GitHub.