Edition 0 Updated to asp. Net core 0

Test Http retries and circuit breakers in eShopOnContainers 
Whenever you start the eShopOnContainers solution in a Docker host, it needs to start multiple 
containers. Some of the containers are slower to start and initialize, like the SQL Server container. This 
is especially true the first time you deploy the eShopOnContainers application into Docker because it 
needs to set up the images and the database. The fact that some containers start slower than others 
can cause the rest of the services to initially throw HTTP exceptions, even if you set dependencies 
between containers at the docker-compose level, as explained in previous sections. Those docker-
compose dependencies between containers are just at the process level. The container’s entry point 
process might be started, but SQL Server might not be ready for queries. The result can be a cascade 
of errors, and the application can get an exception when trying to consume that particular container. 
You might also see this type of error on startup when the application is deploying to the cloud. In that 
case, orchestrators might be moving containers from one node or VM to another (that is, starting new 
instances) when balancing the number of containers across the cluster’s nodes.
The way ‘eShopOnContainers’ solves tho
se issues when starting all the containers is by using the Retry 
pattern illustrated earlier. 
Test the circuit breaker in eShopOnContainers 
There are a few ways you can break/open the circuit and test it with eShopOnContainers. 
One option is to lower the allowed number of retries to 1 in the circuit breaker policy and redeploy 
the whole solution into Docker. With a single retry, there’s a good chance that an HTTP request will 
fail during deployment, the circuit breaker will open, and you get an error. 
Anoth
er option is to use custom middleware that’s implemented in the 
Basket
microservice. When 
this middleware is enabled, it catches all HTTP requests and returns status code 500. You can enable 
the middleware by making a GET request to the failing URI, like the following: 
•
GET http://localhost:5103/failing
This request returns the current state of the middleware. If the middleware is enabled, the 
request return status code 500. If the middleware is disabled, there’s no response.
•
GET http://localhost:5103/failing?enable
This request enables the middleware. 
•
GET http://localhost:5103/failing?disable
This request disables the middleware. 
For instance, once the application is running, you can enable the middleware by making a request 
using the following URI in any browser. Note that the ordering microservice uses port 5103. 
http://localhost:5103/failing?enable

---

310 
CHAPTER 7 | Implement resilient applications 
You can then check the status using the URI 
http://localhost:5103/failing
, as shown in Figure 8-
5. 
Figure 8-5. Checking the state 
of the “Failing” ASP.NET middleware –
 In this case, disabled. 
At this point, the Basket microservice responds with status code 500 whenever you call invoke it. 
Once the middleware is running, you can try making an order from the MVC web application. Because 
the requests fail, the circuit will open. 
In the following example, you can see that the MVC web application has a catch block in the logic for 
placing an order. If the code catches an open-circuit exception, it shows the user a friendly message 
telling them to wait.