Repository navigation
[fix](fe) Close the FileIO of an Iceberg HiveCatalog that fails to initialize - #70164
Conversation
…itialize ### What problem does this PR solve? Issue Number: None Related PR: apache#66913 Problem Summary: Iceberg 1.12's HiveCatalog#initialize creates the FileIO first, then the Hive client pool, and only then the CloseableGroup that closes the FileIO. When the client pool fails (an unknown element in `client-pool-cache-keys`, for example) or the metrics reporter fails to load, HiveCatalog#close has no group to close, and DorisHiveCatalog had not captured the FileIO yet, so nothing closes it. IcebergConnector caches only a catalog that initialized, so such a catalog creates and drops one FileIO on every metadata access. branch-4.x (apache#66913) closes it; master did not. With the FileIOs master configures (HadoopFileIO, and the lazily initialized ResolvingFileIO and S3FileIO) nothing native leaks today. DorisHiveCatalog#initialize now closes the FileIO HiveCatalog created when initialization throws, and rethrows; a close failure is added to it as suppressed. ### Release note None ### Check List (For Author) - Test: Unit Test - New DorisHiveCatalogTest#closesFileIOWhenHiveClientPoolInitializationFails (from apache#66913): an unknown cache key element fails initialization and the FileIO is closed once; without the change it is never closed. - Behavior changed: No - Does this need documentation: No Co-authored-by: 924060929 <lanhuajian@selectdb.com> Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Thank you for your contribution to Apache Doris. Please clearly describe your PR:
|
|
run buildall |
|
/review |
|
Codex automated review failed and did not complete. Error: Selected model is at capacity. Please try a different model. Please inspect the workflow logs and rerun the review after the underlying issue is resolved. |
|
/review |
FE UT Coverage ReportIncrement line coverage `` 🎉 |
|
Codex automated review failed and did not complete. Error: Selected model is at capacity. Please try a different model. Please inspect the workflow logs and rerun the review after the underlying issue is resolved. |
TPC-H: Total hot run time: 28826 ms |
TPC-DS: Total hot run time: 151467 ms |
ClickBench: Total hot run time: 24.25 s |
|
/review |
|
Codex automated review failed and did not complete. Error: Selected model is at capacity. Please try a different model. Please inspect the workflow logs and rerun the review after the underlying issue is resolved. |
|
run feut |
|
run cloud_p0 |
FE UT Coverage ReportIncrement line coverage `` 🎉 |
|
/review |
|
Codex automated review failed and did not complete. Error: Selected model is at capacity. Please try a different model. Please inspect the workflow logs and rerun the review after the underlying issue is resolved. |
|
/review |
|
Codex automated review failed and did not complete. Error: Selected model is at capacity. Please try a different model. Please inspect the workflow logs and rerun the review after the underlying issue is resolved. |
Local pipeline review — ✅ PASSschema: doris-repo-review/v1
status: PASS
pr: apache/doris#70164
commit: 327978a44bc2fe8a973973831531196c598e435d
base: c0274bfb4accd3f013b320704d55919f7ae46c2e
reviewed_at: 2026-11-06T09:00+08:00
reviewer: morningman
model: gpt-6.1-sol
effort: xhigh
findings: {blocker: 0, major: 0, minor: 0, nit: 0}
rounds: 1
converged: trueNotes for maintainers None. Reviewed locally with the |
What problem does this PR solve?
Issue Number: None
Related PR: #66913, #66914
Problem Summary:
In short. This ports from branch-4.x #66913 the cleanup of an Iceberg
HiveCatalogwhose initialization fails after it has created its FileIO: on master, nothing closes that FileIO. With the FileIOs master configures, the leaked object holds no native resource today, so this is hygiene that keeps a FileIO with real resources from leaking once per failed catalog creation.Background.
DorisHiveCatalog(fe-connector-iceberg, used for Iceberg on HMS) extends Iceberg'sHiveCatalogand owns the FileIO the catalog creates (#66914). In Iceberg 1.12,HiveCatalog#initializecreates the FileIO first, then the Hive client pool, and only then theCloseableGroupthat closes the FileIO, the KMS client and the metrics reporter. #66913, the branch-4.1 port of #66914, closes the FileIO when initialization fails; master'sDorisHiveCatalogdoes not.The problem, and what it cost. When
CachedClientPoolfails (an unknown element inclient-pool-cache-keys, aclientsthat is not a number) or the metrics reporter fails to load (metrics-reporter-impl), the catalog has a FileIO but no group:HiveCatalog#closecloses nothing, andDorisHiveCataloghas not captured the FileIO yet. The catalog properties reach Iceberg as the user gave them, andIcebergConnectorcaches only a catalog that initialized, so each metadata access on such a catalog creates and drops another FileIO. Today that is only garbage: master's HMS catalogs useHadoopFileIO, whoseclosedoes nothing, andResolvingFileIOandS3FileIOcreate their clients lazily.How this PR fixes it. When
HiveCatalog#initializethrows,DorisHiveCatalog#initializecloses the FileIO the catalog created and rethrows; a failure to close is added to the initialization failure as suppressed. The FileIO is null when loading the FileIO itself failed, and then there is nothing to close. Not ported from #66913: itsclose()changes, since Iceberg 1.12 (#69031) closes the FileIO inHiveCatalog#closeitself, and itsDorisHadoopCatalog. The hadoop flavor has the same order (HadoopCatalogcreates the FileIO before the lock manager), but master uses Iceberg'sHadoopCatalog, and a subclass would change the catalog-impl mapping without freeing anything today.Results.
client-pool-cache-keyswith an unknown elementDorisHiveCatalog#initializeIllegalArgumentException, the FileIO stays openIllegalArgumentException, the FileIO is closedOriginal author: @924060929
Release note
None
Check List (For Author)
Test
New
DorisHiveCatalogTest#closesFileIOWhenHiveClientPoolInitializationFails(from branch-4.1: [fix](metacache) release Iceberg FileIO and Hudi fsView on cache eviction #66914 #66913) has the catalog load a FileIO that counts its closes, throughio-impl, and fail on an unknown cache key element: the FileIO is closed once. Without the change it is never closed (expected 1 but was 0). The other case of the class passes, and fe-connector-iceberg Checkstyle reports nothing.Behavior changed:
Does this need documentation?
Check List (For Reviewer who merge this PR)