You are absolutely right! I never ran into issues with exhausting the sockets because of how small my testing domain has been so far, but I can see how this would have bit me down the road in our production environment. So you not only saved me a headache later down the road, but I've updated my examples as well. Thank you friend!
In case anyone else is curious, here's what I learned!
HttpClient is intended to be instantiated once and re-used throughout the life of an application. Instantiating an HttpClient class for every request will exhaust the number of sockets available under heavy loads. This will result in SocketException errors.
Cheers. Another thing I noticed. .Result can in some cases cause deadlocks, iirc. I would change method signature to asynchronous Task and await everything within methods body. Along with wrapping HttpRequestMessage in a using statement or simply using var request Update = ....
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
You are absolutely right! I never ran into issues with exhausting the sockets because of how small my testing domain has been so far, but I can see how this would have bit me down the road in our production environment. So you not only saved me a headache later down the road, but I've updated my examples as well. Thank you friend!
In case anyone else is curious, here's what I learned!
HttpClient is intended to be instantiated once and re-used throughout the life of an application. Instantiating an HttpClient class for every request will exhaust the number of sockets available under heavy loads. This will result in SocketException errors.
Cheers. Another thing I noticed.
.Resultcan in some cases cause deadlocks, iirc. I would change method signature to asynchronous Task and await everything within methods body. Along with wrappingHttpRequestMessagein a using statement or simplyusing var request Update = ....