5

By default HttpClient only uses 2 concurrent connections per host. According to docs I can change that. I don't want to change it on a global level, I just want to change it for the service I'm using. Therefore I wrote the following code:

// Increase connection limit in order to have more concurrent requests to MyService
ServicePointManager.FindServicePoint(myServiceUrl, null).ConnectionLimit = 20;

Unfortunately, this doesn't work. The service (called via HttpClient) still uses only 2 concurrent connections. If I change the code to:

ServicePointManager.DefaultConnectionLimit = 20;

At the same code location, it works. However, I don't want to globally change this setting. How to change it locally only?

Edit: I realized that something is setting the connection limit back to 2. Is there any operation (e.g., instantiating a new WebRequestHandler, instantiating a new HttpClient, ...?) which resets the connection limit?

D.R.
  • 20,268
  • 21
  • 102
  • 205
  • Make sure the scheme, port and hostname of `myServiceUrl` correspond to the actual service you're calling. – CodeCaster Sep 03 '18 at 13:19
  • Yeah, they are the same. – D.R. Sep 03 '18 at 13:25
  • May the downvoter please elaborate why this is not a programming question and why this question should be closed. Thank you, – D.R. Sep 03 '18 at 13:26
  • You might look at this question and its answers: [How can I programmatically remove the 2 connection limit in WebClient](//stackoverflow.com/q/866350), but given the lack of context here, I'm not sure if it's relevant. You can also see the source code for ConnectionLimit [here](https://github.com/Microsoft/referencesource/blob/master/System/net/System/Net/ServicePoint.cs#L749) – Heretic Monkey Sep 03 '18 at 13:40

1 Answers1

9

I found the problem, we ran into the following .NET bug:

https://github.com/Microsoft/dotnet/blob/master/releases/net471/KnownIssues/534719-Networking.ServicePoint.ConnectionLimit%20default%20behavior%20changed.md

D.R.
  • 20,268
  • 21
  • 102
  • 205
  • 1
    i hit this bug on `net462` (despite the KnownIssues page says it was introduced in `net471`). one can simply run a test that's mentioned in the KnownIssues link above for the framework they are targeting to verify if the bug exists. in net frameworks (so not netcore, and net), i'm seeing this bug fixed only on `net472`, `net48`. hope this helps. – hIpPy Apr 28 '21 at 21:07