yuqi1129 opened a new issue, #13591: URL: https://github.com/apache/gravitino/issues/13591
## Version main branch, `8e9ca0009d68dbf9edb5e313d3d51688b9c4cff1`; MySQL 8.0.35, mysql-connector-j 8.0.33, Java 17. ## Describe what's wrong With the default catalog pool size of 10, concurrent ALTERs on distinct tables can consume every pool slot with outer connections and then wait for another connection inside SQL generation. This is connection-pool starvation, released by timeouts rather than a JVM monitor deadlock. A 32-client reproduction attempting table-comment updates recorded 33 attempts: 25 HTTP 500s and 8 successes. All successful responses took about 30.5 seconds. The nominal five-second phase actually lasted 30.53 seconds because it drained in-flight requests. No same-table contention was required. ## Error message and/or stacktrace `Cannot get a connection, pool error Timeout waiting for idle object, borrowMaxWaitDuration=PT30S` A thread dump shows 10 requests in `GenericObjectPool.borrowObject` -> `JdbcTableOperations.load` -> `getOrCreateTable` -> `MysqlTableOperations.generateAlterTableSql`, while retaining the outer connection obtained in `JdbcTableOperations.alterTable`. Another 22 requests wait at the outer borrow. ## How to reproduce 1. Configure a jdbc-mysql catalog with the default `jdbc.pool.max-size=10`. Use a JDBC URL selecting an existing default database to avoid the separate connection-reuse issue. 2. Create 32 disposable tables with columns and comments. 3. Send 32 concurrent `updateComment` alterTable requests, one per distinct table. Capture a thread dump while blocked. 4. Observe nested connection borrows and the 30-second pool timeout. Column operations that load the original definition follow the same source path. ## Additional context `JdbcTableOperations.alterTable` obtains a connection before calling `generateAlterTableSql`. The MySQL generator calls `getOrCreateTable` to retain Gravitino's identifier in comments; this calls `load` and borrows a second connection. Reuse the caller's connection or generate the SQL before occupying its execution connection. A deterministic component probe gates two callers after their outer borrow: with pool size 2 and a 500 ms wait, both actual MySQL generators time out; with pool size 4 both succeed in about 70–74 ms. The gate and shortened timeout are probe-only. Merely raising pool size is a workload-dependent workaround. The reproduction used the default authorizer and ordinary authorized writers; the issue is in catalog connection management, not permission denial. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
