2

I am looking at implementing a HttpClient as a static to avoid socket exhaustion. (If using an instance per call, you end up with a socket stuck in TIME_WAIT for 4 minutes, and if you perform enough calls or have enough instances of your application running in parallel, you will run out of sockets). I am also aware of the DNS caching problem that this approach causes and will add the suitable ConnectionLeaseTimeout.

But my question relates to the one static HttpClient that remains.

The first link shows the following example code:

private static HttpClient Client = new HttpClient();

But being IDisposable, it should be disposed once it is no longer required (ie, during application shutdown)? Whilst it may be unnecessary for a pure HttpClient, what if there is a handler that uses unmanaged resources? How could I call dispose this? Or more specifically, is there an event to which I can subscribe to make sure this occurs?

Edit:

This question differs from the suggested duplicate in two important ways.

  1. That ticket is asked in the context of httpclient instance per call. Indicating that standard usage is not to dispose after every request is self evidently not what my question was suggesting.
  2. The phrase

The HttpClient object is intended to live for as long as your application needs to make HTTP requests

implies that after your application no longer needs to make HTTP requests is when the disposal should rather happen. Other questions and resources have indicated that IDisposable is required if the handler has unmanaged resources.

In fact I asked this question after reviewing that and several other SO questions to make sure there was no answer. If my question is a duplicate, terrific, I didn't find it though and importantly the suggested duplicate doesn't address this.

mjwills
  • 23,389
  • 6
  • 40
  • 63
Adam G
  • 1,283
  • 1
  • 6
  • 15
  • This is not a duplicate of that question. That question is that it should not be disposed after every request and that it should live "as long as your application needs to make HTTP requests". This does not negate the need to dispose after such time, especially where handlers are involved. – Adam G May 17 '18 at 02:08
  • I've re-opened. The previous duplicate question was not a duplicate. – Enigmativity May 17 '18 at 02:51
  • Surely as the last line in the `Main` method would be the place to dispose an object that might be required right up until then. – jmcilhinney May 17 '18 at 02:58
  • @jmcilhinney, thanks, good point. I didn't think it relevant at the time, but should have mentioned that I am in a dll here (and more strictly speaking, an interop library being invoked by unmanaged code). Of course these things are much simpler in a console app. I could, I guess, add another method that the caller should call to dispose everything but I was hoping there might be some event that the runtime fires before it unloads my library. – Adam G May 17 '18 at 03:16
  • @mjwills, thanks for your reply, that was the ticket this previously was marked duplicate of. That specific answer links to Darrel Miller's blog post. The recommendation on disposal relates to the typical IDisposable in a using block usage pattern, which is not recommended. That doesn't mean it shouldn't be disposed ever, just not between each call. Ever will eventually come, my question is about that point in time if you take the static approach – Adam G May 17 '18 at 03:59
  • The GC is not guaranteed to dispose at the moment your application closes. In this case, you are releasing these resources / handles / whatever to make them available for the OS and other applications, not your own. Maybe it is my OCD at play, but it is surely best practice to explicitly dispose any unmanaged resources at the end of your application? – Adam G May 17 '18 at 05:29
  • Does the OS release resources and handles automatically when a process closes? – mjwills May 17 '18 at 06:01

0 Answers0