apache/seatunnel · warning

JDBC connection close failed.

Error message

JDBC connection close failed.

What it means

A log warning in DdsqlJdbcConnectionPoolProviderProxy.closeConnection: closing a pooled JDBC connection (via poolManager.remove(queueIndex).close()) threw a SQLException. The connection is discarded from the pool anyway; this is a cleanup-path warning and does not fail the running operation. Typically the connection was already dead (stale/broken) when the pool tried to close it.

Source

Thrown at seatunnel-connectors-v2/connector-jdbc/src/main/java/org/apache/seatunnel/connectors/seatunnel/jdbc/internal/dialect/dsql/DdsqlJdbcConnectionPoolProviderProxy.java:66

    public boolean isConnectionValid() throws SQLException {
        return poolManager.containsConnection(queueIndex)
                && poolManager
                        .getConnection(queueIndex)
                        .isValid(jdbcConfig.getConnectionCheckTimeoutSeconds());
    }

    @Override
    public Connection getOrEstablishConnection() {
        return poolManager.getConnection(queueIndex);
    }

    @Override
    public void closeConnection() {
        if (poolManager.containsConnection(queueIndex)) {
            try {
                poolManager.remove(queueIndex).close();
            } catch (SQLException e) {
                log.warn("JDBC connection close failed.", e);
            }
        }
    }

    @Override
    public Connection reestablishConnection() {
        closeConnection();
        return getOrEstablishConnection();
    }
}

View on GitHub (pinned to cf67b549a7)

Solutions

1. Verify network stability between SeaTunnel workers and the dSQL server; check firewall/LB idle timeout settings and raise them or enable TCP keepalive on the JDBC URL
2. Confirm the database did not kill the session (check server-side session/kill logs, max_idle_time settings)
3. Reduce connection idle time in the pool or enable validation/validationQuery so dead connections are detected before reuse
4. If the warning is frequent but jobs succeed, it is benign cleanup noise; investigate only when accompanied by connection failures in the job

Example fix

// before: jdbc url without keepalive
dm://host:5236?schema=xxx
// after: add socket timeout / keepalive options appropriate for the ddsql driver
dm://host:5236?schema=xxx&socketTimeout=300000&keepAlive=true

// check connectivity before/at job start
try (Connection c = DriverManager.getConnection(url, user, pass)) {
    // if this fails, fix network/credentials before submitting the job
}

// wrap pool/reconnect operations and retry on SQLException
try {
    closeConnection();
} catch (SQLException e) {
    log.warn("JDBC connection close failed, discarding connection", e);
    // proceed: connection is already removed from the pool
}

When it happens

Trigger: closeConnection() called (e.g. from reestablishConnection when replacing a broken connection, or pool shutdown) and the underlying Connection.close() throws SQLException because the socket is already broken, the DB closed it server-side, or a network drop occurred.

Common situations: Long-lived dSQL (Dameng/DWS ddsql) connections killed by firewall idle timeouts; database restart while SeaTunnel workers hold pooled connections; network partitions in k8s/VM environments; replacing a failed connection during job recovery.

Related errors

• Timed out after <actualSeconds> seconds while waiting to con
• Read the binlog offset error
• DATABASE_NOT_EXISTED
• Failed listing table in catalog %s
• Unsupported constraint type:

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