Skip to content

Fixed connection pooling in the UrlConnectionHttpClient. #2660

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

Merged
merged 2 commits into from
Aug 12, 2021

Conversation

millems
Copy link
Contributor

@millems millems commented Aug 12, 2021

No description provided.

response.responseBody().ifPresent(IoUtils::drainInputStream);
}

assertThat(CONNECTION_COUNTER.openedConnections()).isLessThan(initialOpenedConnections + 5);
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we be more precise than lessThan here? It seems like this should be deterministic. Do we expect exactly initialOpenedConnections, initialOpenedConnections + 1?

Copy link
Contributor

@Bennett-Lynch Bennett-Lynch Aug 12, 2021

Choose a reason for hiding this comment

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

I guess the number may depend (and thus vary) upon the client implementation, and how many times we're willing to reuse a connection. Is it fair to say that no client ought to use more than 1 new connection here though? Can we do: isLessThanOrEqualTo(initialOpenedConnections + 1)?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

In my tests it was fairly consistently +1 when pooling was working, or +5 when it was not working.

Because the test is so indirect (involves cooperation of various HTTP client implementations as well as Wiremock/Jetty, I wasn't confident that hard-coding it to +1 was going to create a 100% deterministic test, and non-deterministic tests are worse than no test (IMO). I think if it's < 5 we can confidently say that connection pooling is working, but you're right that we don't know to what extent it's working. With the test how it currently is, we could make a change that makes pooling "worse" (whatever that means) without this test catching it, unless it completely breaks pooling altogether.

Let me try running it a few thousand times to see if it ever fails at +1.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I switched it to +1, it seemed to work just fine. We can reassess if it becomes a problem.

Comment on lines +81 to +85
// Note: This socket factory MUST be reused between requests because the connection pool in the JVM is keyed by both
// URL and SSLSocketFactory. If the socket factory is not reused, connections will not be reused between requests.
SSLSocketFactory socketFactory = getSslContext(options).getSocketFactory();

this.connectionFactory = url -> createDefaultConnection(url, socketFactory);
Copy link
Contributor

Choose a reason for hiding this comment

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

Awesome find and nice documentation.

@millems millems force-pushed the millem/fix-url-connection-pooling branch from fe88941 to 76f808b Compare August 12, 2021 17:17
@sonarqubecloud
Copy link

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 4 Code Smells

100.0% 100.0% Coverage
0.0% 0.0% Duplication

@millems millems merged commit 35f57d3 into master Aug 12, 2021
@millems millems deleted the millem/fix-url-connection-pooling branch August 12, 2021 18:16
aws-sdk-java-automation added a commit that referenced this pull request Aug 15, 2023
…a9ddd34b8

Pull request: release <- staging/c325cf33-678b-449e-b810-b49a9ddd34b8
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.

2 participants