What causes "Close JDBC writer failed." in apache/seatunnel?

Check the logged cause: if it follows a FLUSH_DATA_FAILED error, fix that root cause first

Close JDBC writer failed.

Error message

Close JDBC writer failed.

What it means

closeStatements() attempts to close the underlying JdbcStatementExecutor's statements when the writer is closed. Any SQLException or JdbcConnectorException is caught, logged as a warning ('Close JDBC writer failed.'), and swallowed — it never propagates to the task. This is a best-effort cleanup log, not a task failure.

Source

Thrown at seatunnel-connectors-v2/connector-jdbc/src/main/java/org/apache/seatunnel/connectors/seatunnel/jdbc/internal/JdbcOutputFormat.java:253

                flush();
            } catch (Exception e) {
                LOG.warn("Writing records to JDBC failed.", e);
                flushException =
                        new JdbcConnectorException(
                                CommonErrorCodeDeprecated.FLUSH_DATA_FAILED,
                                "Writing records to JDBC failed.",
                                e);
            }
        }
    }

    public void closeStatements() {
        try {
            if (jdbcStatementExecutor != null) {
                jdbcStatementExecutor.closeStatements();
            }
        } catch (SQLException | JdbcConnectorException e) {
            LOG.warn("Close JDBC writer failed.", e);
        }
    }

    private boolean isOverMaxBatchSizeLimit() {
        return jdbcConnectionConfig.getBatchSize() > 0
                && batchCount >= jdbcConnectionConfig.getBatchSize();
    }

    private boolean isOverMaxBatchIntervalLimit() {
        long batchIntervalMs = jdbcConnectionConfig.getBatchIntervalMs();
        return batchIntervalMs > 0
                && (System.currentTimeMillis() - lastFlushTimeMs) >= batchIntervalMs;
    }

    public void updateExecutor(boolean reconnect) throws SQLException, ClassNotFoundException {
        try {
            jdbcStatementExecutor.closeStatements();
        } catch (SQLException | JdbcConnectorException e) {

View on GitHub (pinned to cf67b549a7)

Solutions

Check the logged cause: if it follows a FLUSH_DATA_FAILED error, fix that root cause first
Verify network/firewall idle-timeout settings that kill connections before job close
Upgrade the JDBC driver if it throws spuriously on close of dead statements
Treat this warning as benign cleanup noise if all records were flushed successfully

Example fix

null

Defensive patterns

Strategy: try-catch

Validate before calling

// before closing, verify connection liveness
if (connection != null && !connection.isValid(5)) {
    log.info("connection already dead; close warning expected");
}

Try / catch

try {
    outputFormat.close();
} catch (Exception e) {
    // close() itself rarely throws for this path; watch logs for 'Close JDBC writer failed.'
    log.warn("cleanup close issue", e);
}

Prevention

Fix earlier FLUSH_DATA_FAILED errors — most close failures follow them
Keep connections alive across job duration (timeouts, keepalive)
Monitor this warning only; it is non-fatal by design

When it happens

Trigger: close() -> closeStatements() while the underlying Connection/Statement is already broken (connection reset, socket timeout) or the driver throws SQLException on Statement.close().

Common situations: Database restarted or network dropped before job completion (common when a prior flush already failed); driver-specific quirks throwing on close of a dead statement; leaked statements after long-running jobs.

Understand the failure class

Background: Database query failed: Internal Server Error 500s wrapping SQL, Prisma, and connection failures — what to check first — this error's family across 16 libraries.

Related errors

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