yuqi1129 commented on issue #12986: URL: https://github.com/apache/gravitino/issues/12986#issuecomment-5583179937
Widened the investigation to every provider that can be run locally. Four more retention paths turned up, all unrelated to the first three and all confirmed the same way, by tracing a heap dump back to a GC root: - `DriverManager.registeredDrivers` holds the catalog's JDBC driver. It cannot be removed from the server's ClassLoader: `DriverManager` filters both `getDrivers()` and `deregisterDriver()` by the caller's ClassLoader, so `ClassLoaderPool.deregisterAllDrivers` never saw, let alone deregistered, anything. Every JDBC catalog was affected. - PostgreSQL's driver starts a `LazyCleaner` thread whose class the catalog defined; a running thread is a GC root regardless of its context ClassLoader. - MySQL Connector/J keeps an abandoned-connection cleanup executor in a static field whose thread factory is a lambda the catalog defined. This also hit `lakehouse-iceberg` on a JDBC backend. - Hadoop's cloud connectors install a JCA security provider (the shaded `OpenSSLProvider` in the AWS bundle) into the JVM-wide `Security` list, which hit `fileset` on `abfss://`. Coverage now verified end-to-end for `model`, `fileset` on file://, s3a, gs:// and abfss://, `jdbc-mysql`, `jdbc-postgresql`, `kafka`, `hive`, `lakehouse-paimon` and `lakehouse-iceberg` on a JDBC backend: every one releases its ClassLoader after a drop. `glue`, `jdbc-doris`, `jdbc-starrocks`, `lakehouse-hudi` and `lakehouse-generic` were not reachable locally; Doris and StarRocks use the MySQL driver, so the JDBC fixes apply to them unchanged. #12987 has the details and the measurements. -- 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]
