apache/seatunnel · warning
Failed to close connection
Error message
Failed to close connection
What it means
MySqlSourceFetchTaskContext.close() closes the JDBC connection and disconnects the binary-log client. If connection.close() throws a SQLException, this warning is logged with the exception while the binaryLogClient disconnect is skipped, because both calls share a single try block.
Source
Thrown at seatunnel-connectors-v2/connector-cdc/connector-cdc-mysql/src/main/java/org/apache/seatunnel/connectors/seatunnel/cdc/mysql/source/reader/fetch/MySqlSourceFetchTaskContext.java:201
new MySqlStreamingChangeEventSourceMetrics(
taskContext, queue, metadataProvider));
this.snapshotChangeEventSourceMetrics =
changeEventSourceMetricsFactory.getSnapshotMetrics(
taskContext, queue, metadataProvider);
this.streamingChangeEventSourceMetrics =
(MySqlStreamingChangeEventSourceMetrics)
changeEventSourceMetricsFactory.getStreamingMetrics(
taskContext, queue, metadataProvider);
this.errorHandler = new MySqlErrorHandler(connectorConfig, queue);
}
@Override
public void close() {
try {
this.connection.close();
this.binaryLogClient.disconnect();
} catch (SQLException e) {
log.warn("Failed to close connection", e);
} catch (IOException e) {
log.warn("Failed to close binaryLogClient", e);
}
}
@Override
public MySqlSourceConfig getSourceConfig() {
return (MySqlSourceConfig) sourceConfig;
}
public MySqlConnection getConnection() {
return connection;
}
public BinaryLogClient getBinaryLogClient() {
return binaryLogClient;
}
View on GitHub (pinned to cf67b549a7)
Solutions
- If seen during normal shutdown, it is harmless — the connection was already dead; verify the task completed otherwise.
- Reorder/fix code so each resource is closed independently (try-with-resources or separate try blocks) so the binaryLogClient still gets disconnected.
- Check MySQL server logs and network stability (wait_timeout, max_allowed errors) if it appears frequently.
- Upgrade the connector/driver version if double-close races are involved.
Example fix
// before
try {
this.connection.close();
this.binaryLogClient.disconnect();
} catch (SQLException e) { log.warn("Failed to close connection", e); }
// after
try { this.connection.close(); } catch (SQLException e) { log.warn("Failed to close connection", e); }
try { this.binaryLogClient.disconnect(); } catch (IOException e) { log.warn("Failed to close binaryLogClient", e); } Defensive patterns
Strategy: try-catch
Try / catch
try (Connection c = dataSource.getConnection()) {
// work
} // auto-close handles already-closed connections safely Prevention
- Close the JDBC connection and BinaryLogClient in independent try/catch blocks
- Treat close-time SQLException during shutdown as benign; focus on the original failure
- Tune wait_timeout/keepalives for long incremental reads
- Avoid double-close paths (cancel followed by close)
When it happens
Trigger: close() is called during reader/task teardown; this.connection.close() throws SQLException (connection already closed, socket broken, driver error) and the warning is logged before binaryLogClient.disconnect() can run.
Common situations: Task shutdown after a MySQL server restart or network drop (connection already dead); double-close when the reader is cancelled and then closed; long-running incremental read where the connection timed out before close.
Related errors
- Failed to close binaryLogClient
- Failed to shutdown MySQL abandoned connection cleanup thread
- Error reading MySQL variables:
- Unexpected error while connecting to MySQL and looking at GT
- Unexpected error while connecting to MySQL and looking at pr
AI-assisted analysis of apache/seatunnel@cf67b549a7 (2026-09-10).
Data as JSON: /api/errors/f202738829dfc4dd.
Report an issue: GitHub.