Edition 0 Updated to asp. Net core 0

Additional resources 
•
Connection Resiliency and Command Interception with EF in an ASP.NET MVC Application
https://learn.microsoft.com/aspnet/mvc/overview/getting-started/getting-started-with-ef-using-
mvc/connection-resiliency-and-command-interception-with-the-entity-framework-in-an-asp-
net-mvc-application
 
•
Cesar de la Torre. Using Resilient Entity Framework Core SQL Connections and 
Transactions
https://devblogs.microsoft.com/cesardelatorre/using-resilient-entity-framework-core-sql-
connections-and-transactions-retries-with-exponential-backoff/
 
Use IHttpClientFactory to implement resilient HTTP 
requests 
IHttpClientFactory
 is a contract implemented by 
DefaultHttpClientFactory
, an opinionated factory, 
available since .NET Core 2.1, for creating 
HttpClient
 instances to be used in your applications. 
Issues with the original HttpClient class available in .NET 
The original and well-known 
HttpClient
 
class can be easily used, but in some cases, it isn’t being 
properly used by many developers. 
Though this class implements 
IDisposable
, declaring and instantiating it within a 
using
statement is 
not preferred because when the 
HttpClient
object gets disposed of, the underlying socket is not 
immediately released, which can lead to a 
socket exhaustion
problem. For more information about this 
issue, see the blog post 
You’re using HttpClient wrong and it’s destabilizing your software
. 
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
. This can be a good solution for short-lived 
console apps or similar, that run a few times a day. 

---

300 
CHAPTER 7 | Implement resilient applications 
Another issue that developers run into is when using a shared instance of 
HttpClient
in long-running 
processes. In a situation where the HttpClient is instantiated as a singleton or a static object, it fails to 
handle the DNS changes as described in this 
issue
 of the dotnet/runtime GitHub repository. 
However, the issue isn’t really with 
HttpClient
per se, but with the 
default constructor for HttpClient
, 
because it creates a new concrete instance of 
HttpMessageHandler
, which is the one that has 
sockets 
exhaustion
and DNS changes issues mentioned above. 
To address the issues mentioned above and to make 
HttpClient
instances manageable, .NET Core 
2.1 introduced two approaches, one of them being 
IHttpClientFactory
. It’s an interface that’s used
to 
configure and create 
HttpClient
instances in an app through Dependency Injection (DI). It also 
provides extensions for Polly-based middleware to take advantage of delegating handlers in 
HttpClient. 
The alternative is to use 
SocketsHttpHandler
with configured 
PooledConnectionLifetime
. This 
approach is applied to long-lived, 
static
or singleton 
HttpClient
instances. To learn more about 
different strategies, see 
HttpClient guidelines for .NET
. 
Polly
 is a transient-fault-handling library that helps developers add resiliency to their applications, by 
using some pre-defined policies in a fluent and thread-safe manner.