yuqi1129 opened a new issue, #13296:
URL: https://github.com/apache/gravitino/issues/13296
### Version
main branch / branch-1.3
### Describe what's wrong
On `branch-1.3`, `MetalakeManager.dropMetalake(ident, force=true)` only
deletes the metalake entity from the store. The `CatalogWrapper`s of its
catalogs stay in `CatalogManager.catalogCache` (the only eviction is
`expireAfterAccess`), so catalog resources such as JDBC connection pools are
never closed. Dropping catalogs individually goes through
`CatalogManager.dropCatalog`, which invalidates the cache entry and closes the
wrapper, and does release the connections.
With ~60 JDBC / Iceberg-JDBC catalogs on one PostgreSQL server the leaked
connections exhaust the default `max_connections=100`; after the metalake is
dropped the connections stay held until the Gravitino server is restarted.
`main` already force-drops child catalogs through
`CatalogManager.dropCatalog` (introduced as part of #12420), but there is no
test that pins this behaviour. `branch-1.3` does not have it.
Expected:
1. Dropping a metalake closes every catalog in it, releasing their
connections and other resources, exactly as dropping each catalog does.
2. No catalog resource outlives the metalake that owned it.
### Error message and/or stacktrace
No error on the Gravitino side. PostgreSQL eventually refuses new clients
(`FATAL: sorry, too many clients already`) and later Iceberg catalog creates
fail with `Failed to connect`.
### How to reproduce
1. Create a metalake with 15 `jdbc-postgresql` catalogs and 15
`lakehouse-iceberg` catalogs (JDBC backend), all pointing at one PostgreSQL
server. Give each catalog's JDBC URL a distinct `ApplicationName` so its
connections can be counted in `pg_stat_activity`.
2. List schemas in each catalog once.
3. `DELETE /api/metalakes/{metalake}?force=true`
| Point | Open connections from the probe catalogs |
|---|---|
| With 30 catalogs | 32 |
| Metalake drop returns 200 | |
| 15 s after the drop | 32 |
| 75 s after the drop | 32 |
Dropping the catalogs one at a time (`DELETE
.../catalogs/{catalog}?force=true`) instead leaves 0 open.
### Additional context
_No response_
--
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]
