Fix file descriptor leaks in ServerStatusManager - #1331
Merged
Conversation
…Executor Motivation: `Files.newInputStream()` and `Files.newOutputStream()` allocate real OS file descriptors. `Properties.load()` and `Properties.store()` do not close the stream passed to them, so the caller is responsible for closing it. The descriptors are eventually reclaimed by GC, but GC is triggered by memory pressure rather than FD exhaustion. Modifications: - `ServerStatusManager.serverStatus()`: wrap `Files.newInputStream()` in try-with-resources so the stream is closed after `Properties.load()`. - `ServerStatusManager.updateStatus()`: same fix for the load path; also wrap `Files.newOutputStream()` in try-with-resources so the stream is closed after `Properties.store()`. Result: - File descriptors opened for property file I/O are now released deterministically instead of relying on GC finalisation.
📝 WalkthroughWalkthroughThe pull request updates file IO in replay revision and server status handling to use Java try-with-resources, while preserving existing revision-file and status-property behavior. ChangesFile resource management
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (1)
server/src/main/java/com/linecorp/centraldogma/server/internal/replication/ZooKeeperCommandExecutor.java (1)
775-775: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueSpecify UTF-8 charset in
InputStreamReaderfor consistency with the write path.
updateLastReplayedRevision(line 789) writes usingStandardCharsets.UTF_8, butgetLastReplayedRevisionreads vianew InputStreamReader(new FileInputStream(...))which uses the platform default charset. This is a pre-existing inconsistency, not introduced by this PR, and is practically harmless for numeric strings. Since this method is being touched, consider aligning the charset.♻️ Optional charset alignment
- try (BufferedReader br = new BufferedReader(new InputStreamReader(new FileInputStream(revisionFile)))) { + try (BufferedReader br = new BufferedReader( + new InputStreamReader(new FileInputStream(revisionFile), StandardCharsets.UTF_8))) {🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@server/src/main/java/com/linecorp/centraldogma/server/internal/replication/ZooKeeperCommandExecutor.java` at line 775, In getLastReplayedRevision, update the InputStreamReader construction to explicitly use StandardCharsets.UTF_8, matching the charset used by updateLastReplayedRevision when writing the revision file.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In
`@server/src/main/java/com/linecorp/centraldogma/server/internal/replication/ZooKeeperCommandExecutor.java`:
- Line 775: In getLastReplayedRevision, update the InputStreamReader
construction to explicitly use StandardCharsets.UTF_8, matching the charset used
by updateLastReplayedRevision when writing the revision file.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 6b5f33d7-710c-4be1-91a3-015128dc44c6
📒 Files selected for processing (2)
server/src/main/java/com/linecorp/centraldogma/server/internal/replication/ZooKeeperCommandExecutor.javaserver/src/main/java/com/linecorp/centraldogma/server/management/ServerStatusManager.java
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
3 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.
Motivation:
Files.newInputStream()andFiles.newOutputStream()allocate real OS file descriptors.Properties.load()andProperties.store()do not close the stream passed to them, so the caller is responsible for closing it. The descriptors are eventually reclaimed by GC, but GC is triggered by memory pressure rather than FD exhaustion.Modifications:
ServerStatusManager.serverStatus(): wrapFiles.newInputStream()in try-with-resources so the stream is closed afterProperties.load().ServerStatusManager.updateStatus(): same fix for the load path; also wrapFiles.newOutputStream()in try-with-resources so the stream is closed afterProperties.store().Result: