mailtoboggavarapu-coder opened a new pull request, #19861: URL: https://github.com/apache/hudi/pull/19861
### Describe the issue this Pull Request addresses `HoodieAvroDataBlock.decompress()` creates an `InflaterInputStream` but never closes it. Unlike a `ByteArrayInputStream` (which holds no external resources), `InflaterInputStream` wraps a `java.util.zip.Inflater` object that allocates native (off-heap) zlib memory via JNI. This native memory is not managed by the JVM garbage collector — it must be released explicitly by calling `Inflater.end()`, which only happens through `InflaterInputStream.close()`. Without closing the stream, native zlib memory leaks on every call — both on the normal exit path and when an `IOException` is thrown. In archived timeline reads where this method is called repeatedly, the leaked native memory accumulates and can eventually cause `OutOfMemoryError: native memory exhausted` even when heap memory is available. Notably, the sibling `compress()` method in the same class already correctly uses try-with-resources for `DeflaterOutputStream`. This fix makes `decompress()` consistent with `compress()`. ### Summary and Changelog Wrapped the `InflaterInputStream` in a try-with-resources statement in `HoodieAvroDataBlock.decompress()`, ensuring `close()` is always called to release the native zlib `Inflater` resources. - `HoodieAvroDataBlock.java`: Added try-with-resources to `InflaterInputStream` in `decompress()`, consistent with the existing try-with-resources usage in `compress()`. ### Impact No behaviour change. Prevents native memory leaks in archived timeline reads that invoke `decompress()`. ### Risk Level low — One-line structural change; no logic change to decompression behaviour. ### Documentation Update none ### Contributor's checklist - [ ] Read through [contributor's guide](https://hudi.apache.org/contribute/how-to-contribute) - [ ] Enough context is provided in the sections above - [ ] 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]
