dkranchii opened a new pull request, #18405: URL: https://github.com/apache/pinot/pull/18405
`FilePerIndexDirectory.removeIndex()` was dropping the buffer entry from the cache map without calling `close()` on it. For mmap-backed buffers (the default for offline segments), this means the kernel mapping leaks for the lifetime of the JVM — the on-disk file does get deleted, but the address-space mapping stays until the process exits (or the `Cleaner` happens to fire, which we shouldn't rely on for deterministic cleanup). `removeIndex()` is hit during segment reloads, minion-driven segment conversions, and the various `*IndexHandler` drop/replace flows, so on long-running servers that churn through reloads this shows up as the classic. The class itself had a `// TODO` flagging this, so this PR just finishes it. ## Scope Single file: pinot-segment-local/src/main/java/org/apache/pinot/segment/local/segment/store/FilePerIndexDirectory.java ~10 lines changed No public API change, no behavior change for callers — removeIndex still returns void, still cleans up the on-disk files exactly the same way, just additionally closes the cached buffer. ## Testing Existing FilePerIndexDirectoryTest still passes. Manually verified the flow: with the fix, the PinotDataBuffer.close() on the removed entry is invoked once; without the fix it never was. ### Fixes #18404 ## Release note none (memory leak fix, no user-visible behavior change) -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
