rehansaeed/httpclientsample

A sample ASP.NET Core project showing how to configure the HttpClientFactory

I am a professional Software Developer at Microsoft and blogger at RehanSaeed.com. Although I work for Microsoft, my opinions are my own. If it’s written in C# or .NET, I have probably written something using it in anger!

I live stream my software development escapades on Youtube and Twitch twice a week. Feel free to join me live and ask questions.

‏‏‎ ‎

You can see some of the open source projects that I have started and maintained in my portfolio. There are many others I have contributed to which you can see in my GitHub profile and of course there are other commercial projects that I cannot disclose.

‏‏‎ ‎ ‏‏‎ ‎

I have been fairly active on StackOverflow. You can view my Stack Overflow profile and see my contribution to the community.

Before I joined Microsoft, I was a Microsoft Most Valuable Professional (MVP) for three years. This gave me inside information into the work Microsoft was doing. Once I joined Microsoft, I had to give up this award.

Here are some of the awards I have been given for my work as a software engineer in open source or elsewhere:

Do you have questions or comments about my work? Please feel free to contact me.

httpclientsample's Issues

SocketException errors (TCP connection limit reached)

Hi,

Thank you for this HttpClientSample, it helped me a lot to implement HttpClientFactory inside an ASP.NET core 2.2 application.

I used exactly the same implementation as yours, but still, I got a lot of SocketException with this error message :

An attempt was made to access a socket in a way forbidden by its access permissions

As you can see, my app crash every time Azure app service plan TCP connection limit has been reached (seems to be 700 for B1 plan) :

Steve Gordon said this :

When you add a typed client it will be registered as a transient service in Dependency Injection, so you will always get a fresh instance with a fresh HttpClient created for you by the factory. The factory will manage the underlying handler lifetime for that HttpClient instance, re-using a handler (and connection) if available.

HttpClientFactory is not supposed to address those issues and handle lifetime management of underlying resources like TCP connections ? What do you recommend ?

Microsoft documentation stated :

Therefore, HttpClient is intended to be instantiated once and reused throughout the life of an application. Instantiating an HttpClient class for every request will exhaust the number of sockets available under heavy loads. That issue will result in SocketException errors. Possible approaches to solve that problem are based on the creation of the HttpClient object as singleton or static, as explained in this Microsoft article on HttpClient usage.

But there’s a second issue with HttpClient that you can have when you use it as singleton or static object. In this case, a singleton or static HttpClient doesn’t respect DNS changes, as explained in this issue at the .NET Core GitHub repo.

To address those mentioned issues and make the management of HttpClient instances easier, .NET Core 2.1 introduced a new HttpClientFactory that can also be used to implement resilient HTTP calls by integrating Polly with it.

Maybe I could try using typed clients from a singleton service like as it is described here :

https://www.stevejgordon.co.uk/ihttpclientfactory-patterns-using-typed-clients-from-singleton-services

But I'm not sure if it's the best way for my application. I'm developing a status website for an online game, who makes requests day and night to the game's API to get the status of the backend servers. This application is often under heavy loads during game maintenance or downtime periods.

The current implementation of this website in production use Node.js but I rewrote it from scratch with ASP.NET core 2.2, I learn at the same time how ASP.NET Core 2 works 😃 The new service is in beta since today and I observe this issue after few hours.

I can share application sources if needed, but it's mostly what you did.

Best Regards.

@stevejgordon

Suggestions

Hi Rehan,

I came to this repository from your blog post on how to optimally configure an ASP.NET Core HttpClientFactory.

First I'd like to say thanks for writing this up, as it is always very helpful to see real world examples of how people configure this stuff in their projects. Secondly I knew it's going to be good as soon as I read

"I don’t know why the ASP.NET team bothered to provide three ways to register a client, the typed client is the one to use."

;)

Now here's some questions/suggestions:

Another possibility I’ve not tried is to combine these two scenarios, so you have two circuit breakers. The curcuit breaker with the lower limit would kick in first but only break the circuit for a short time, if exceptions are no longer thrown, then things go back to normal quickly. If exceptions continue to be thrown, then the other circuit breaker with a longer duration of break would kick in and the circuit would be broken for a longer period of time.

Is there currently no way in Polly to achieve this with a single circuit breaker? I think this would be an optimal implementation, because the longer a service is broken, the less it makes sense to periodically keep hitting it. I think there must be a way to configure the circuit breaker to either have an exponential break like the retry policy can have, or we should raise this as a feature request in the Polly repository.

..., it looks like they consider any of the below as transient errors:
Any HttpRequestException thrown. This can happen when the server is down.
A response with a status code of 408 Request Timeout.
A response with a status code of 500 or above.

I think this is a good start, but when speaking about optimally configuring a HttpClient I think a default policy (which really every http client in .NET Core should always use - without exceptions) would be to respect a 429 Too many requests response with an optional Retry-After http header which tells the client for how long to back off. This should be IMHO a standard circuit breaker policy, because there is no point for a client to even retry or hit a second time the server from another request if the API is rate limiting the client. At this point the only sensible option is to back off via a circuit break for at least the given time in Retry-After. Would love to see that in your blog post being covered, because a lot of folks will probably use that as a template for optimal configuration.

Another topic which I personally am interested and I don't find much useful information in the official Polly documentation is logging. For debugging purposes I think it would be useful to have access to an ILogger<T> object inside the policy which would allow us to log when a circuit is broken for a long time for example. I'd love to have somewhere a _logger.LogDebug(...) call so when I want to turn the log level up in a local environment I can follow in my logs when certain events are being triggered.

There were my main questions/suggestions which I think would add huge value when talking about optimally configuring this stuff, so it can be useful in a real world scenario. Would love to hear your thoughts on this!

Query : Is it possible to use HTTPClientFactory in ASP.NET core 2.0 ?

Read your blog post on using HTTPClientFactory in ASP.NET core 2.1 , Is it possible to use HTTPClientFactory in ASP.NET core 2.0 ?.