fix: HoodieStorage resource leak in FileSystemBasedLockProvider.close()#18461
Conversation
mailtoboggavarapu-coder
left a comment
There was a problem hiding this comment.
Pinging for an initial review. This PR fixes a genuine resource leak: FileSystemBasedLockProvider creates a HoodieStorage (which holds underlying filesystem connections and implements Closeable) in its constructor but never closes it in close(). The fix is a one-liner — calling storage.close() inside the existing close() method so the resource is released every time the lock provider is torn down.
Would appreciate a review from a committer with write access to apache/hudi (@vinothchandrasekar / @alexeykudinkin / @danny0405 / @nsivabalan).
| try { | ||
| storage.close(); | ||
| } catch (IOException e) { | ||
| LOG.warn("Failed to close storage in FileSystemBasedLockProvider", e); |
There was a problem hiding this comment.
good catch, can you fix the indentation.
CI Build Failures — Master Branch Issue (not this PR)The Evidence:
The CI situation is being tracked. Once the master build stabilises, a re-run of CI on this PR should pass. cc @vinothchandrasekar @alexeykudinkin @danny0405 @nsivabalan — would appreciate a re-run once the master build issue is resolved. |
|
There is compile error: /home/runner/work/hudi/hudi/hudi-client/hudi-client-common/src/main/java/org/apache/hudi/client/transaction/lock/FileSystemBasedLockProvider.java:[118,10] class, interface, enum, or record expected |
|
@danny0405 Thank you for merging #18457 and #18467! This PR (#18461) fixes a |
CI Re-triggered After Master FixMaster has advanced past the broken This branch has been synced with the updated master and an empty commit was pushed to re-trigger CI. CI results on this run should be clean. |
f9c08ff to
cb096a1
Compare
Adds a finally block to properly close the HoodieStorage instance after the lock file is deleted, preventing resource leaks. Fixes apache#14922
cb096a1 to
a88509f
Compare
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #18461 +/- ##
=========================================
Coverage 68.85% 68.86%
- Complexity 28241 28256 +15
=========================================
Files 2460 2460
Lines 135348 135351 +3
Branches 16410 16407 -3
=========================================
+ Hits 93200 93206 +6
- Misses 34770 34771 +1
+ Partials 7378 7374 -4
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
|
Hi @danny0405, all 55 CI checks are now passing ✅ for this PR. This fix ensures Would you be able to review and merge when you get a chance? Thanks! |
yihua
left a comment
There was a problem hiding this comment.
🤖 This review was generated by an AI agent and may contain mistakes. Please verify any suggestions before applying.
Thanks for contributing! The change is safe and follows good resource management practice. One thing worth noting: HoodieHadoopStorage.close() is intentionally a no-op to avoid closing the JVM-cached Hadoop FileSystem, so the actual resource leak fix may not have impact with the default storage backend today — see inline comment for details.
| throw new HoodieLockException(generateLogStatement(LockState.FAILED_TO_RELEASE), e); | ||
| } finally { | ||
| try { | ||
| storage.close(); |
There was a problem hiding this comment.
🤖 Worth noting that HoodieHadoopStorage.close() is intentionally a no-op (it avoids closing the cached Hadoop FileSystem). So this won't actually release resources with the default storage implementation today. Still reasonable to add for correctness with potential future storage backends, but wanted to flag this so the impact is clear.
- Generated by an AI agent and may contain mistakes. Please verify any suggestions before applying.
yihua
left a comment
There was a problem hiding this comment.
🤖 This review was generated by an AI agent and may contain mistakes. Please verify any suggestions before applying.
Style & Readability Review — one minor suggestion to simplify the log message.
| try { | ||
| storage.close(); | ||
| } catch (IOException closeEx) { | ||
| log.warn("Failed to close HoodieStorage in FileSystemBasedLockProvider", closeEx); |
There was a problem hiding this comment.
🤖 nit: could you simplify the log message to just 'Failed to close HoodieStorage'? The logger already provides the class context automatically.
- Generated by an AI agent and may contain mistakes. Please verify any suggestions before applying.
yihua
left a comment
There was a problem hiding this comment.
🤖 This review was generated by an AI agent and may contain mistakes. Please verify any suggestions before applying.
LGTM — clean fix for a genuine resource leak. The finally block correctly ensures storage.close() runs regardless of the deleteFile outcome, and the caught IOException avoids masking the original exception.
Describe the issue this Pull Request addresses
FileSystemBasedLockProvidercreates aHoodieStorageinstance in its constructor but never closes it in theclose()method. SinceHoodieStorageimplementsCloseableand holds underlying filesystem connections, this causes a resource leak every time the lock provider is closed.Summary and Changelog
Fixed a resource leak in
FileSystemBasedLockProvider.close()by ensuringHoodieStorageis always closed.FileSystemBasedLockProvider.java: Added afinallyblock inclose()to callstorage.close()after the lock file deletion attempt.IOExceptionfromstorage.close()is caught and logged as a warning to avoid masking the original exception.Impact
No public API or user-facing change. Prevents filesystem connection accumulation in long-running jobs using the filesystem-based lock provider.
Risk Level
low — Only affects resource cleanup; no functional locking logic changed.
Documentation Update
none
Contributor's checklist