Skip to content

fix: close getObject response stream for buffering transformers - #524

Open
sharmabikram wants to merge 1 commit into
mainfrom
shbikram/getobject-stream-leak
Open

sharmabikram wants to merge 1 commit into
mainfrom
shbikram/getobject-stream-leak

Conversation

@sharmabikram

@sharmabikram sharmabikram commented Sep 24, 2026 •

Copy link
Copy Markdown
Contributor

close getObject response stream for buffering transformers. Fixes #518.

Issue #, if available:

Description of changes:

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Check any applicable:

  • Were any files moved? Moving files changes their URL, which breaks all hyperlinks to the files.

@sharmabikram
sharmabikram requested a review from a team as a code owner September 24, 2026 21:43
* the response stream: buffering transformers do not need the connection left open (so the client
* closes the stream and avoids the leak), while streaming transformers do (the caller closes it).
*/
public class S3EncryptionClientGetObjectStreamCloseTest {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't actually test the updated getObject method, no? Just properties about the SDK classes themselves? So I don't think this would actually fail without the fix

// materialized result, so the stream must be closed here to release its buffers. Streaming
// transformers (e.g. toInputStream) return the stream for the caller to read and close.
if (!responseTransformer.needsConnectionLeftOpen()) {
joinFutureGet.close();

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't close the stream if some exception is thrown in the try block, let's move this to a finally block

S3EncryptionClient.getObject never closed the ResponseInputStream from the
toBlockingInputStream() pipeline, leaking Netty direct memory on every call
with a buffering transformer (getObjectAsBytes, toFile). Close the stream when
the transformer does not need the connection left open; streaming transformers
(toInputStream) still return the stream for the caller to close. Fixes #518.
@sharmabikram
sharmabikram force-pushed the shbikram/getobject-stream-leak branch from 42f58b4 to 55d84e2 Compare September 26, 2026 22:55

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Memory leak in S3EncryptionClient.getObject()

2 participants