Should or should not Httpclient be used within a using block?

Question

Reading this reply, a question relating to the use of using, I was curious about the following statement:

In fact everyone uses HttpClient wrong, I even used and did not know everything, because I trusted that the documentation had everything I needed, but I learned the lesson.

The way I’ve seen it HttpClient be used is within a block using.

using (var http = new HttpClient())
{
    //
}

Not knowing for sure if this is what the AR was referring to, I asked him and, through a commenting, he confirmed that yes.

Since the comment was not sufficiently enlightening, the question remains:

The HttpClient should or should not be used within a block using?

Answer 1

HttpClient client = new HttpClient();

    static async Task Main()
    {
      try   
      {
         HttpResponseMessage response = await client.GetAsync("http://www.contoso.com/");
         response.EnsureSuccessStatusCode();
         string responseBody = await response.Content.ReadAsStringAsync();

         Console.WriteLine(responseBody);
      }  
      catch(HttpRequestException e)
      {
         Console.WriteLine("\nException Caught!");  
         Console.WriteLine("Message :{0} ",e.Message);
      }
    }

The instance of the Httpclient class acts as a session for sending HTTP requests. An Httpclient instance is a collection of settings applied to all requests executed by that instance. In addition, each instance of Httpclient uses its own connection pool, isolating its requests from requests executed by other instances of Httpclient.

According to the documentation found in Microsoft, when there is a single instance of Httpclient for the entire application the ideal is not to use "Using{}", otherwise it is important to make use of "Using{}" when there is more than one instance of Httpclient.

Answer 2

The big problem is precisely that it is misleading. By having implemented the interface IDisposble everyone thinks they should use the using. And I don’t know if in the first implementation of this class I didn’t need, what I do know is that the documentation initially said nothing of this, or because it taught wrong or because it was like this before (you can’t trust 100% documentation, something close to this can, but it never gives all the details).

It makes sense to have this interface in this class because it may actually have reasons for at some point the resource linked to this object being discarded. But the most common use is that it lasts the entire application.

Think about the object, starting with the name. People think of it as a connection but it is a client. How many HTTP clients do you need in your application? One, right? What for? It’s a mechanism, it’s like a file system, You don’t have to have more than one. The fact that you have only one does not mean that you can only make a request, it being there can order whenever you want, as long as you have access to the object.

For some reason there’s nothing static about him like file system, probably because the customer is little heavy and creating will always be something expensive for most applications, while creating every time it needs is too costly (which is the mistake that "everyone" makes).

In the correct form it is very common that this object is placed in a static field, so creates once, possibly in the first effective use, and no longer need, then just use.

The example of the other answer is not very good because it was written anyway. I imagine the intention there was that the field was static. Unless in a very simple example it does not seem appropriate to create in the main class, should have a class with responsibility to take care of it, but there is a mistake of use of the HttpClient but organization of the code.

I learned that if the class has IDisposable always use using

It is not so, it must in methods, that is, when the object must be created locally. And this must be relative, also have cases not to use, although probably has better way to do.

There are cases that you can create the object there, return it and then the object must retain the resource linked to it, so it is not there that will use the using, but will probably use it elsewhere for liberation to be made. Luckily you don’t see it out there, but it is something that can exist and even be useful in some scenario. Something like this:

void Metodo() {
    ...
    using (var arquivo = CriaRecurso()) { ... }
    ...
}

FileStream CriaRecurso() {
    ...
    var file = new FileStream("abc.txt", FileMode.Create)
    ...
    return file;
}

In addition it may be that the object with the resource can be stored within a class through a field and not a local variable. In this case there is no way to use the using what you’ll have to do is at some point call the Dispose() of that object. This can be through a destructor/finalizer method that every object has or through a Dispose() created in this class, so if you use an object that is IDisposable in a field practically forces this class to implement the IDisposable, is viral. Then an object of this class will probably be placed in a using.

It’s more rare to do this, but I’ve seen several scenarios you need. If people did so much code it would be optimized when there are gains.

In some cases it must be even in a static field which can dispense this class go through some destruction.

The lifespan necessary for the object will determine where and whether the using.

You can never use the using in that class?

It can, if you know that your application will only use the HTTP client there once or a very limited amount, then better not to. And I’m not saying it’s the same. It’s worse to do this more than once, it only makes sense if it’s once, at all times of execution. In fact in a scenario like this is better with the using, but it’s rare to have such a scenario.

What goes wrong if you do it like this?

He will create sockets on the operating system. It is unclear why but it does not seem to release immediately and so an hour may run out sockets free. Or even if this does not occur each socket new spent resources on the machine.

There’s a page that shows this with property:

using static System.Console;
using System.Net.Http;

public class Program {
    public static async Task Main() {
        WriteLine("Starting connections");
        for (int i = 0; i<10; i++) {
            using (var client = new HttpClient()) {
                var result = await client.GetAsync("http://aspnetmonsters.com");
                WriteLine(result.StatusCode);
            }
        }
        WriteLine("Connections done");
    }
}

This works and produces this:

C:\code\socket> dotnet run
Project socket (.NETCoreApp,Version=v1.0) will be compiled because inputs were modified
Compiling socket for .NETCoreApp,Version=v1.0

Compilation succeeded.
    0 Warning(s)
    0 Error(s)

Time elapsed 00:00:01.2501667


Starting connections
OK
OK
OK
OK
OK
OK
OK
OK
OK
OK
Connections done

But investigating in the operating system see what happened:

C:\code\socket>NETSTAT.EXE
...
  Proto  Local Address          Foreign Address        State
  TCP    10.211.55.6:12050      waws-prod-bay-017:http  TIME_WAIT
  TCP    10.211.55.6:12051      waws-prod-bay-017:http  TIME_WAIT
  TCP    10.211.55.6:12053      waws-prod-bay-017:http  TIME_WAIT
  TCP    10.211.55.6:12054      waws-prod-bay-017:http  TIME_WAIT
  TCP    10.211.55.6:12055      waws-prod-bay-017:http  TIME_WAIT
  TCP    10.211.55.6:12056      waws-prod-bay-017:http  TIME_WAIT
  TCP    10.211.55.6:12057      waws-prod-bay-017:http  TIME_WAIT
  TCP    10.211.55.6:12058      waws-prod-bay-017:http  TIME_WAIT
  TCP    10.211.55.6:12059      waws-prod-bay-017:http  TIME_WAIT
  TCP    10.211.55.6:12060      waws-prod-bay-017:http  TIME_WAIT
  TCP    10.211.55.6:12061      waws-prod-bay-017:http  TIME_WAIT
  TCP    10.211.55.6:12062      waws-prod-bay-017:http  TIME_WAIT
  TCP    127.0.0.1:1695         SIMONTIMMS742B:1696    ESTABLISHED
...

Bad, right? Imagine it happening a thousand times.

using static System.Console;
using System.Net.Http;

public class Program {
    private static HttpClient Client = new HttpClient();
    public static async Task Main() {
        WriteLine("Starting connections");
        for (int i = 0; i<10; i++) {
            var result = await client.GetAsync("http://aspnetmonsters.com");
            WriteLine(result.StatusCode);
        }
        WriteLine("Connections done");
    }
}

I put in the Github for future reference.

The result is the same but now the operating system reports only one socket.

Note that this is ok because it is an example only for tests, the object and resource will be discarded at the end of the application that is when we want, but there are cases that need a more sophisticated control. Don’t always think this shape is the most suitable for your case, so it is necessary to learn how to do things broadly and not just decorate cake recipes.

Completion.

We need to understand everything about what we will use. Often it is not enough to read the official documentation, have to look for other documents, question. Programming is hard, even trying to do everything right can still go wrong.

The problem is that in the past the documentation did not say that life time should probably be the same as the whole application.

Some recommended readings:

• Anti Pattern
• Using HttpClientFactory (in many cases it is more recommended to do this)
• More information about the factory
• Article in the documentation
• Current documentation shows correct