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

HttpClient is disposed and recreated too often #13

Open
loudenvier opened this issue Nov 7, 2017 · 0 comments
Open

HttpClient is disposed and recreated too often #13

loudenvier opened this issue Nov 7, 2017 · 0 comments

Comments

@loudenvier
Copy link

The HttpClient instance should be held to as mush as possible. It should have been possible to pass a HttpClient to Sender, as to prevent Sender from going out of scope and "killing" its internal HttpClient instance. Microsoft own words:

HttpClient is intended to be instantiated once and re-used throughout the life of an application. Especially in server applications, creating a new HttpClient instance for every request will exhaust the number of sockets available under heavy loads. This will result in SocketException errors.

(found here: https://docs.microsoft.com/en-us/aspnet/web-api/overview/advanced/calling-a-web-api-from-a-net-client )

There are a few ways to implement this: allow Sender to be configured with an HttpClient instance created elsewhere, make HttpClient static, create a Settings class which holds the HttpClient instance and lives outside the scope of Sender, etc.

Maybe you've created Sender to live as long as the application (just like the HttpClient), but if so then the sample code is misleading since it surrounds the instantiation of the Sender class with a using clause, suggesting it should be disposed as soon as possible (and its own HttpClient together with it).

rburnham52 pushed a commit to rburnham52/FCM.Net that referenced this issue Feb 6, 2018
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

No branches or pull requests

1 participant