daguimu opened a new pull request, #10219: URL: https://github.com/apache/rocketmq/pull/10219
## Problem `DumpCompactionLogCommand.execute()` creates a `RandomAccessFile` to obtain a `FileChannel`, but neither resource is ever closed. The anonymous `RandomAccessFile` is immediately discarded after `.getChannel()`, making it impossible to close. This leaks file descriptors on every invocation. ## Root Cause The code uses `new RandomAccessFile(fileName, "rw").getChannel()` as a one-liner, discarding the `RandomAccessFile` reference. Neither the `RandomAccessFile` nor the `FileChannel` is wrapped in a try-with-resources block or closed in a finally block. ## Fix - Wrap both `RandomAccessFile` and `FileChannel` in a try-with-resources statement to ensure they are always closed after use. - Changed the file mode from `"rw"` to `"r"` since the command only reads (dumps) the compaction log, it does not need write access. The `MapMode` was also changed from `READ_WRITE` to `READ_ONLY` to match. ## Tests Added | Change Point | Test | |-------------|------| | try-with-resources for resource cleanup | `testExecuteWithValidFile()` — writes a message, dumps it, verifies no resource leak (file still accessible) | | Read-only mode handles empty files | `testExecuteWithEmptyFile()` — verifies graceful handling of empty files | | Non-existent file throws exception | `testExecuteWithNonExistentFile()` — verifies SubCommandException is thrown | | Missing -f option | `testExecuteWithoutFileOption()` — verifies error message is printed without exception | ## Impact Only affects the `dumpCompactionLog` CLI tool. No changes to broker runtime or message processing logic. Fixes #10218 -- 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]
