mengw15 opened a new pull request, #7539:
URL: https://github.com/apache/texera/pull/7539

   ### What changes were proposed in this PR?
   
   `IcebergCatalogInstance` kept one catalog client per warehouse name for the 
life of the process; with per-user warehouses (#6870) that set is unbounded, 
and each REST catalog holds an HTTP client. The map is now a Guava cache 
(`maximumSize` 64 + `expireAfterAccess` 60 min, mirroring 
`HuggingFaceModelResource`'s bounded-cache precedent) whose removal listener 
closes evicted catalogs; the next access simply rebuilds one.
   
   For eviction to be safe, holders stop pinning a catalog: `IcebergDocument`'s 
`lazy val` becomes a per-use `def`, and `IcebergTableWriter` now takes the 
warehouse (not a `Catalog`) and resolves per use — a replaced or rebuilt 
catalog is picked up immediately. The lookup rides Guava's per-key locking, 
dropping the previous JVM-wide `synchronized` that held one lock across a cache 
miss's REST config round trip. `replaceInstance` skips a same-instance re-put: 
Guava reports one as a replacement, which would close a catalog that is still 
installed (parallel test suites re-register one shared catalog).
   
   Also dedupes `DocumentFactory`'s three copies of the URI→(warehouse, 
namespace, storage key) decode block into one resolver, as promised in #6944 
review.
   
   ### Any related issues, documentation, discussions?
   
   Closes #7290.
   
   ### How was this PR tested?
   
   New `IcebergCatalogInstanceSpec`: a genuine replacement closes the displaced 
catalog, a same-instance re-put does not, and `IcebergDocument` sees a 
replacement immediately (pinning the per-use `def` against a pinned `lazy 
val`). Existing iceberg suites (`IcebergDocumentSpec`, 
`IcebergTableWriterSpec`, `OnIcebergSpec`, `DocumentFactorySpec`) pass locally 
— 51 tests. Size-based eviction is deliberately not exercised: it would flood 
the JVM-wide cache parallel suites share; it flows through the same removal 
listener the replacement cases pin.
   
   ### Was this PR authored or co-authored using generative AI tooling?
   
   Generated-by: Claude Code (claude-fable-5)
   


-- 
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]

Reply via email to