Apache Iceberg version
1.11.0 (latest release)
Query engine
Other
Please describe the bug 🐞
When a MySQL-backed JdbcCatalog connection is dropped by the server (for example an idle connection closed at wait_timeout), the pool does not recover it:
UncheckedSQLException: Failed to execute exists query: SELECT ... FROM iceberg_tables ...
Caused by: com.mysql.cj.jdbc.exceptions.CommunicationsException: Communications link failure
Caused by: java.net.SocketException: Broken pipe
The failure does not clear on the next call. ClientPoolImpl.release returns the client with addFirst, so the dead connection goes back to the head of the pool and is handed to the next caller.
JdbcClientPool already reconnects on connection failures, but only for SQLTransientException and the SQLSTATEs in COMMON_RETRYABLE_CONNECTION_SQL_STATES. MySQL's CommunicationsException extends SQLRecoverableException — a sibling of SQLTransientException, not a subtype — and reports SQLSTATE 08S01, which is not in that set. Neither check matches, so no reconnect is attempted.
Same symptom as #14317.
Proposed fix: treat SQLRecoverableException as retryable. The JDBC contract for that type is that recovery requires closing the connection and obtaining a new one, which is what JdbcClientPool.reconnect does. Adding 08S01 to the default SQLSTATEs would fix MySQL only.
On existing releases, retryable_status_codes=08S01 works as a workaround.
PR: #17828
Apache Iceberg version
1.11.0 (latest release)
Query engine
Other
Please describe the bug 🐞
When a MySQL-backed
JdbcCatalogconnection is dropped by the server (for example an idle connection closed atwait_timeout), the pool does not recover it:The failure does not clear on the next call.
ClientPoolImpl.releasereturns the client withaddFirst, so the dead connection goes back to the head of the pool and is handed to the next caller.JdbcClientPoolalready reconnects on connection failures, but only forSQLTransientExceptionand the SQLSTATEs inCOMMON_RETRYABLE_CONNECTION_SQL_STATES. MySQL'sCommunicationsExceptionextendsSQLRecoverableException— a sibling ofSQLTransientException, not a subtype — and reports SQLSTATE08S01, which is not in that set. Neither check matches, so no reconnect is attempted.Same symptom as #14317.
Proposed fix: treat
SQLRecoverableExceptionas retryable. The JDBC contract for that type is that recovery requires closing the connection and obtaining a new one, which is whatJdbcClientPool.reconnectdoes. Adding08S01to the default SQLSTATEs would fix MySQL only.On existing releases,
retryable_status_codes=08S01works as a workaround.PR: #17828