Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wrap GZIPInputStream with a ConsumingInputStream to drain on close #749

Closed
wants to merge 2 commits into from

Conversation

chingor13
Copy link
Collaborator

Fixes #367

@chingor13 chingor13 requested a review from a team as a code owner July 15, 2019 23:40
@googlebot googlebot added the cla: yes This human has signed the Contributor License Agreement. label Jul 15, 2019
@@ -356,6 +357,44 @@ public InputStream getContent() throws IOException {
return content;
}

static class ConsumingInputStream extends InputStream {
Copy link
Contributor

Choose a reason for hiding this comment

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

An outer class would better separate unrelated code. This is complex enough to justify it.

public void close() throws IOException {
if (!closed && inputStream != null) {
try {
drainInputStream(this);
Copy link
Contributor

Choose a reason for hiding this comment

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

Why is it important to drain the input stream and throw away the excess data, instead of simply closing the stream?

try (ByteArrayOutputStream byteStream = new ByteArrayOutputStream(dataToCompress.length)) {
GZIPOutputStream zipStream = new GZIPOutputStream((byteStream));
zipStream.write(dataToCompress);
zipStream.close();
Copy link
Contributor

Choose a reason for hiding this comment

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

We should probably also have a case where there's extra data on the stream after the gzipped content, since handling that is the purpose of this PR.

}
}

static void drainInputStream(final InputStream inputStream) throws IOException {
Copy link
Contributor

Choose a reason for hiding this comment

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

I think this method can be private. Also you've reinvented ByteStreams.exhaust from Guava.

codyoss added a commit to codyoss/google-http-java-client that referenced this pull request Oct 14, 2019
If a connection is closed and there are some bytes that have not
been read that connection can't be reused. Now GZIPInputStream
will have all of its bytes read on close automatically to promote
connection reuse.

Checkpicked from: googleapis#749
Fixes: googleapis#367
codyoss added a commit to codyoss/google-http-java-client that referenced this pull request Oct 14, 2019
If a connection is closed and there are some bytes that have not
been read that connection can't be reused. Now GZIPInputStream
will have all of its bytes read on close automatically to promote
connection reuse.

Cherry-picked: googleapis#749
Fixes: googleapis#367
codyoss added a commit that referenced this pull request Oct 18, 2019
If a connection is closed and there are some bytes that have not
been read that connection can't be reused. Now GZIPInputStream
will have all of its bytes read on close automatically to promote
connection reuse.

Cherry-picked: #749
Fixes: #367
@chingor13 chingor13 closed this Oct 22, 2019
@chingor13 chingor13 deleted the chunked-keepalive branch October 22, 2019 00:37
clundin25 pushed a commit to clundin25/google-http-java-client that referenced this pull request Aug 11, 2022
* fix: timing of stale token refreshes on ComputeEngine

ComputeEngine metadata server has its own token caching mechanism that will return a cached token until the last 5 minutes of its expiration. This has a negative interaction with stale token refreshes because stale token refresh kicks in T-6mins until T-5mins. This will cause every stale refresh to return the same stale token.

This PR updates the timing for ComputeEngineCredentials to start a stale refresh at T-4mins and consider the token expired at T-3 mins. The implementation is a bit noisy because it includes a change OAuth2Credentials to make the thresholds configureable and now that we targeting java8, I migrated to using java8 time data types

* fmt

* fix test

* fix test again

* remove debug code

* comments
clundin25 pushed a commit to clundin25/google-http-java-client that referenced this pull request Aug 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cla: yes This human has signed the Contributor License Agreement.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

chunked encoding + GZIP prevents keep-alive
3 participants