yuqi1129 commented on PR #12987:
URL: https://github.com/apache/gravitino/pull/12987#issuecomment-5594338800
The Backend Integration Test failure was mine, and it had a clear signature:
`CatalogHive{2,3}IT` and `CatalogHive3ITWithCatalog`/`CatalogHiveS3IT` all
failed on the same two cases, `testAlterCatalogProperties` and
`testListTables`, with
```
Failed to operate object [...] operation [DROP] under [...],
reason [Thread was interrupted while waiting for lock]
```
Cause: the last commit matched a thread against the ClassLoader by the
classes on its **stack**. A request thread serving an operation on the catalog
being altered has the catalog's frames on its stack, so cleanup interrupted it
mid-request. Altering a catalog releases and re-acquires the pooled
ClassLoader, which is why exactly those two tests caught it.
Fixed in 2cc3a6b: ownership is read from the thread itself again, its own
class, its runnable or its context ClassLoader, never from what it happens to
be executing. I re-ran the leak measurements after the revert and
`jdbc-postgresql`, `jdbc-mysql`, `hive` and `fileset` on s3a all still release
their ClassLoader, so the stack rule was contributing nothing that is verified:
it was written for the AWS idle-connection reaper and never fixed that either,
which is #13016 and needs the Glue catalog to close its client.
Added `testRunningWithClassLoaderIgnoresAThreadOnlyExecutingTheLoadersCode`
so this cannot come back silently.
--
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]
