voonhous opened a new pull request, #19935: URL: https://github.com/apache/hudi/pull/19935
### Describe the issue this Pull Request addresses `HadoopFSUtils.getFSDataInputStream` takes the `FSDataInputStream` a filesystem returns, pulls out its inner `FSInputStream`, buffers that and hands the buffered stream to callers. Closing what Hudi returns closes the file, but never the object the filesystem created. Filesystems that track the streams they hand out, such as Spark's test `DebugFilesystem`, therefore report every Hudi log file read as leaked although the OS stream is closed. Found by TestStreamingSource on #19932: once the two `StreamTest` suites ran in a JVM where `DebugFilesystem` was the cached local filesystem, the suite aborted with "There are 26 possibly leaked file streams", 23 of them from this path. On master the check never sees Hudi's reads, because the SQL suites cache a plain LocalFileSystem first. ### Summary and Changelog - The stream returned for the `FSInputStream` branch now closes the original `FSDataInputStream` after the buffered wrapper. The inner stream's second close is a no-op by the `Closeable` contract. - Unit test with a `LocalFileSystem` subclass that counts the closes of the streams it hands out. ### Impact Callers see the same stream; only its `close` reaches one more object. ### Risk Level low. The extra close targets a wrapper whose inner stream is already closed. ### Documentation Update none ### Contributor's checklist - [x] Read through [contributor's guide](https://hudi.apache.org/contribute/how-to-contribute) - [x] Enough context is provided in the sections above - [x] Adequate tests were added if applicable -- 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]
