-
Notifications
You must be signed in to change notification settings - Fork 135
Disposing HttpClient in GraphQLHttpClient #329
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
Comments
Good question... is there any good reason to dispose of It's propably more a thing of "cleaning up after itself" (a object should clean up all the resources it grabbed when it's disposed of). |
This is actually the reason why I posted this question. Theoretically you can check if HttpClient was instantiated internally or passed as constructor dependency and then either dispose it or do nothing. We did run into socket exhaustion and the only place where dispose is called on HttpClient is GraphQLHttpClient. |
Why do you dispose of |
Well I think it's absolutely logical to call dispose on the objects that implement IDisposible, however It's not me, it's DI container.
Since GraphQLHttpClient is IDisposable it will be disposed when a web request is done. Alternatively we could try a singleton but according to the article that I posted above we might get DNS issues. It's highly unlikely but still possible. I think it still makes sense to dispose HttpClient only when it was created inside GraphQLHttpClient, otherwise(if it's passed as a constructor dependency) it should be the responsibility of the calling code to decide when the httpclient should be disposed. |
I totally support that, but there is that strange behaviour of
Correct, will be adressed... But the way you configure |
The disposing behavoir has been fixed in v3.2.3. Please make sure you configure your DI container to inject |
I wonder if there is any good reason to call Dispose on the HttpClient in the GraphQLHttpClient.
graphql-client/src/GraphQL.Client/GraphQLHttpClient.cs
Line 198 in 5356743
There are several articles in the internet that describe why it's bad. Like this one https://www.aspnetmonsters.com/2016/08/2016-08-27-httpclientwrong/
The text was updated successfully, but these errors were encountered: