[#819] Release the log when a changelog DB constructor cannot read its limits - #833
Open
vharseko wants to merge 1 commit into
Open
Conversation
…uctor cannot read its limits FileReplicaDB opened its log and read the CSN limits afterwards: when that read failed, the constructor threw with the Log instance already reference counted in the JVM-wide log cache and nobody left to close it. The entry stayed pinned together with its file handles, and the next open of the same path got the stale instance back. FileChangeNumberIndexDB had the same shape around its change number initialization. Close the log before rethrowing, as shutdown() does with the same log.
maximthomas
approved these changes
Aug 3, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #819.
FileReplicaDBopened its log first and read the CSN limits afterwards: when that read failed (an unreadable changelog file, the #802 scenario), the constructor threw with theLoginstance already reference-counted in the JVM-wideLog.logsCacheand nobody left to close it — the instance holding the reference was never returned. The cache entry stayed pinned for the lifetime of the JVM together with its file handles, and the next open of the same path got the stale instance back: in the test suite that means aLogwhose files aremoveDB()may have deleted in the meantime (the class of cascades behind #813).FileChangeNumberIndexDBhad the same shape around its change number initialization, so it gets the same guard.Both constructors now close the log before rethrowing, as
shutdown()does with the same log.RuntimeExceptionis covered too, following theLogFileconstructor's own cleanup pattern.The new
FileReplicaDBTest#testFailedConstructorReleasesLogreproduces the leak: it plants a rotated log file with an undecodable record (rotated files are opened without validation — their bounds come from the file name — so reading the oldest CSN is the first operation touching the content), asserts the constructor fails, removes the corrupted file and asserts reopening succeeds. Without the fix the reopen receives the stale cachedLogstill holding the deleted file and fails withCould not open a reader on log file ….