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

  1. If seen during normal shutdown, it is harmless — the connection was already dead; verify the task completed otherwise.
  2. Reorder/fix code so each resource is closed independently (try-with-resources or separate try blocks) so the binaryLogClient still gets disconnected.
  3. Check MySQL server logs and network stability (wait_timeout, max_allowed errors) if it appears frequently.
  4. 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

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


AI-assisted analysis of apache/seatunnel@cf67b549a7 (2026-09-10). Data as JSON: /api/errors/f202738829dfc4dd. Report an issue: GitHub.