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.

Sign up for GitHub

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

Jump to bottom

ConnectionPool exhaustion when using Proxy and MaxConnectionsPerServer #48363

Closed
MihaZupan opened this issue Feb 16, 2021 · 1 comment · Fixed by #50770
Closed

ConnectionPool exhaustion when using Proxy and MaxConnectionsPerServer #48363

MihaZupan opened this issue Feb 16, 2021 · 1 comment · Fixed by #50770
Labels
area-System.Net.Http bug tenet-performance Performance related issue
Milestone
6.0.0

Comments

@MihaZupan
Copy link
Member

When using both an http proxy and setting MaxConnectionsPerServer, SocketsHttpHandler will limit the total number of connections it will open to MaxConnectionsPerServer.

These connections are not shared, so opening some connections to host foo might mean all requests to bar will timeout until foo's pools expire and are reclaimed.

This affects requests that would establish the proxy connection using a CONNECT request - all https and insecure ws requests (HttpConnectionKind.SslProxyTunnel and .ProxyTunnel).

It can be mitigated by ignoring the connection limit on HttpConnectionKind.ProxyConnect connection pools. This mirrors the behavior for http requests where we just connect to the proxy directly without going through the PoolManager for the connect request.

The problem won't be hit if a single handler instance is used for only 1 host.
@MihaZupan MihaZupan added this to the 6.0.0 milestone Feb 16, 2021
@ghost
Copy link

ghost commented Feb 16, 2021

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

When using both an http proxy and setting MaxConnectionsPerServer, SocketsHttpHandler will limit the total number of connections it will open to MaxConnectionsPerServer.

These connections are not shared, so opening some connections to host foo might mean all requests to bar will timeout until foo's pools expire and are reclaimed.

This affects requests that would establish the proxy connection using a CONNECT request - all https and insecure ws requests (HttpConnectionKind.SslProxyTunnel and .ProxyTunnel).

It can be mitigated by ignoring the connection limit on HttpConnectionKind.ProxyConnect connection pools. This mirrors the behavior for http requests where we just connect to the proxy directly without going through the PoolManager for the connect request.

The problem won't be hit if a single handler instance is used for only 1 host.

Author: MihaZupan
Assignees: -
Labels:

area-System.Net.Http
Milestone: 6.0.0

@dotnet-issue-labeler dotnet-issue-labeler bot added the untriaged New issue has not been triaged by the area owner label Feb 16, 2021
@karelz karelz added bug tenet-build-performance Impacts build time: official, developer or CI and removed untriaged New issue has not been triaged by the area owner labels Feb 16, 2021
@MihaZupan MihaZupan added tenet-performance Performance related issue and removed tenet-build-performance Impacts build time: official, developer or CI labels Feb 18, 2021
@geoffkizer geoffkizer mentioned this issue Apr 6, 2021
Merged
@ghost ghost locked as resolved and limited conversation to collaborators May 11, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
area-System.Net.Http bug tenet-performance Performance related issue
Projects
None yet
Milestone
6.0.0
Development

Successfully merging a pull request may close this issue.

some small proxy-related fixes geoffkizer/runtime
2 participants
@karelz @MihaZupan