pjfanning opened a new pull request, #1236: URL: https://github.com/apache/poi/pull/1236
When temp-file buffering is enabled via `ZipInputStreamZipEntrySource.setThresholdBytesForTempFiles`, every entry with an unknown declared size (`entrySize == -1`, e.g. data-descriptor entries written by streaming zip writers) went straight to a temp file, however small it actually was — so enabling the threshold cost a temp file for practically every entry of a streamed zip. This buffers such entries in memory up to the threshold instead, and spills to a temp file (or encrypted temp data, when enabled) only when the entry really turns out to be that large, logging a warning when the spill happens. Small unknown-size entries stay on the heap with no temp file, while an entry that hides its size behind a data descriptor still cannot force more than the threshold into memory. The motivating case is the poi-integration OOM investigated recently: a ~1MB test file whose `xl/styles.xml` (Deflate64, size hidden behind a data descriptor) inflates to ~92MB — just above the minimum inflate ratio and just under the 100MB per-entry cap, so with temp files disabled it is materialised on the heap on every open. Users who enable the temp-file threshold now get full protection from that pattern without paying temp-file I/O for ordinary small entries. Known-size entries behave as before: at or above the threshold they are copied to a temp file, below it they are read into memory (with the recently added size validation). New tests cover: unknown-size entry below the threshold stays in memory (fails against the previous code), and unknown-size entries spilling to plain and encrypted temp files with no data lost. Existing threshold/encryption tests pass unchanged; all `org.apache.poi.openxml4j` tests green. 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- 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]
