apache/seatunnel · warning
close elasticsearch connection error
Error message
close elasticsearch connection error
What it means
EsRestClient.close closes the shared low-level Elasticsearch RestClient; if restClient.close() throws an IOException, this warning is logged and the exception is swallowed. It is a connection-release failure only — reads/writes already completed — so it does not fail the job.
Source
Thrown at seatunnel-connectors-v2/connector-elasticsearch/src/main/java/org/apache/seatunnel/connectors/seatunnel/elasticsearch/client/EsRestClient.java:185
.distribution(
Optional.ofNullable(versionNode.get("distribution"))
.map(JsonNode::asText)
.orElse(null))
.build();
} catch (IOException e) {
throw new ElasticsearchConnectorException(
ElasticsearchConnectorErrorCode.GET_ES_VERSION_FAILED,
"fail to get elasticsearch version.",
e);
}
}
@Override
public void close() {
try {
restClient.close();
} catch (IOException e) {
log.warn("close elasticsearch connection error", e);
}
}
/**
* first time to request search documents by scroll call /${index}/_search?scroll=${scroll}
*
* @param index index name
* @param source select fields
* @param scrollTime such as:1m
* @param scrollSize fetch documents count in one request
*/
public ScrollResult searchByScroll(
String index,
List<String> source,
Map<String, Object> query,
String scrollTime,
int scrollSize) {
return searchByScroll(index, source, query, scrollTime, scrollSize, null, null, null);View on GitHub (pinned to cf67b549a7)
Solutions
- Safe to ignore for correctness — confirm the job's data operations succeeded
- Lower RestClient keep-alive interval below intermediary idle timeouts
- Check Elasticsearch logs for connection resets at that timestamp
- Ensure the client isn't closed twice or used after close
Defensive patterns
Strategy: try-catch
Validate before calling
if (restClient == null) return; // nothing to close // Optionally: GET / on the cluster to confirm liveness before close (diagnostic only)
Try / catch
try { esRestClient.close(); } catch (Exception e) { log.warn("ignoring elasticsearch client close failure", e); } Prevention
- Close each shared client once (guard getOrCreateClientResource teardown against double-close)
- Set keep-alive under LB/firewall idle timeouts
- Treat close-time IOExceptions as non-fatal
When it happens
Trigger: Calling close() (via getOrCreateClientResource teardown or initializeStandaloneClient cleanup) while the underlying HTTP connection is dead, reset by the peer, or already half-closed.
Common situations: Elasticsearch node restart or cluster rebalance during job teardown; idle connection killed by LB/firewall before close; TLS handshake failure on the final close; reusing a client after previous IO errors.
Related errors
- close easysearch connection error
- BULK_RESPONSE_ERROR
- DELETE_PIT_FAILED
- Logout failed while disconnecting, error code -
- DELETE {} response null when clearing scrollId {}
AI-assisted analysis of apache/seatunnel@cf67b549a7 (2026-09-10).
Data as JSON: /api/errors/401b73c755116472.
Report an issue: GitHub.