-
Notifications
You must be signed in to change notification settings - Fork 3.7k
[fix](paimon) Fix Paimon DLF catalog caching issue by adding dlf.catalog.id to cache key #55875
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
Thank you for your contribution to Apache Doris. Please clearly describe your PR:
|
|
run buildall |
|
PR approved by at least one committer and no changes requested. |
|
PR approved by anyone and no changes requested. |
TPC-H: Total hot run time: 34765 ms |
TPC-DS: Total hot run time: 189124 ms |
ClickBench: Total hot run time: 30.07 s |
FE UT Coverage ReportIncrement line coverage |
FE Regression Coverage ReportIncrement line coverage |
…log.id to cache key (#55875) ### What problem does this PR solve? #### Problem: Paimon's CachedClientPool uses a static cache with keys based on clientClassName, metastore.uris, and metastore type. For DLF catalogs, all these values are identical, causing different DLF catalogs with different dlf.catalog_id configurations to incorrectly share the same HMS client pool. This results in the last created catalog's configuration overriding previous ones. #### Root Cause: The cache key construction in CachedClientPool.extractKey() doesn't include DLF-specific configuration differences. Multiple catalogs with different dlf.catalog_id values generate identical cache keys, leading to client pool pollution. #### Solution: Add dlf.catalog_id to the cache key by configuring client-pool-cache.keys = "conf:dlf.catalog.id" in PaimonAliyunDLFMetaStoreProperties.appendCustomCatalogOptions(). This ensures each DLF catalog with a unique catalog_id gets its own HMS client pool.
What problem does this PR solve?
Problem:
Paimon's CachedClientPool uses a static cache with keys based on clientClassName, metastore.uris, and metastore type. For DLF catalogs, all these
values are identical, causing different DLF catalogs with different dlf.catalog_id configurations to incorrectly share the same HMS client pool.
This results in the last created catalog's configuration overriding previous ones.
Root Cause:
The cache key construction in CachedClientPool.extractKey() doesn't include DLF-specific configuration differences. Multiple catalogs with different
dlf.catalog_id values generate identical cache keys, leading to client pool pollution.
Solution:
Add dlf.catalog_id to the cache key by configuring client-pool-cache.keys = "conf:dlf.catalog.id" in
PaimonAliyunDLFMetaStoreProperties.appendCustomCatalogOptions(). This ensures each DLF catalog with a unique catalog_id gets its own HMS client
pool.
Release note
None
Check List (For Author)
Test
Behavior changed:
Does this need documentation?
Check List (For Reviewer who merge this PR)