rangareddy commented on issue #17378: URL: https://github.com/apache/hudi/issues/17378#issuecomment-5351241295
This issue was reviewed as part of the JIRA-migrated backlog triage (HUDI-9181). **Findings: still open, but not actionable as written.** The description is a single line - "Cleaner/safer resource management around `hoodieMetadata` object.. i.e the reader for MT" - with no named class, no leak scenario and no failing case. There is nothing to verify against the code, and nothing a contributor could pick up. It has also aged: searching current `master` for a `hoodieMetadata` field in the Spark index-support and file-index classes turns up nothing, because that area has been reorganised twice since this was filed (the `#19193` / `#19195` hudi-common package moves, and the `#18348` / `#18372` indexer abstraction that reshaped the metadata write path). So even the referent of the ticket is now ambiguous. Could whoever owns HUDI-9176 restate this against the current code - which reader object, what goes wrong (leaked file handles, unclosed readers on an exception path, double-close, reuse after close), and ideally a reproduction? Given it is marked blocker, pinning it down is worth doing before the next release scope is set. Possibly related and more concrete: #17346 (HUDI-8764) covers spillable maps / `BitCaskDiskMap` files from the metadata table not being cleaned up after a JVM kill. If that is the same underlying concern, these should be merged. Keeping this open pending a concrete restatement. -- 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]
