LuciferYang commented on PR #10480: URL: https://github.com/apache/gravitino/pull/10480#issuecomment-4990414243
Correcting my root-cause analysis above — I was wrong about why `TestMultipleJDBCLoad` fails. It's not `AbandonedConnectionCleanupThread`. The real cause is Iceberg's `JdbcCatalog.atomicCreateTable`: before creating its control table it runs `getTables(null, null, "iceberg_tables", null)`, and with MySQL Connector/J's default `nullCatalogMeansCurrent=false` a `null` catalog scans every database on the server. These ITs put several Iceberg JDBC catalogs on separate databases of one shared MySQL container, so the second catalog sees the first's `iceberg_tables`, skips creating its own, and later queries fail with `doesn't exist`. A standalone JDBC probe confirms it: `getTables(null,...)` returns the sibling DB's row by default, 0 rows with `nullCatalogMeansCurrent=true`. Fix is test-only and already in this PR: append `nullCatalogMeansCurrent=true` to the MySQL URIs in `IcebergClassLoaderPoolIT` and `TestMultipleJDBCLoad`. Gravitino passes the user's `uri` through unchanged, so this is a test artifact rather than a product bug, and it's the documented setting for running multiple Iceberg JDBC catalogs on one server. `forkEvery(1)` isn't needed. The combined run fails without the change and is green with it. On the separate PR we agreed on: that was based on my wrong analysis, so I'd re-scope it. The IT failure is handled here. There is a genuine, pre-existing Metaspace leak — MySQL's `AbandonedConnectionCleanupThread` keeps the isolated ClassLoader as its context CL after a catalog is dropped — but it's unrelated to this failure and to the pool, and this PR doesn't depend on it (reverting that hardening keeps the suite green). I'll take it as a follow-up after this PR merges, with its own test, rather than as a precursor. -- 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]
