Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Should Polly Policies be singletons?

I have a query, IGetHamburgers, that calls an external API. I've registered the implementation of IGetHamburgers in my DI container as a Singleton. Im using Polly as a Circuitbreaker, if two requests fails the circuit will open.

My goal is that all calls to the Hamburger api should go through the same circuitbreaker, if GetHamburgers fails, then all other calls should fail as well.

How should I use my Policy? Should I register my Policy as a field like this:

private Policy _policy;

private Policy Policy
{ 
    get 
    {
        if(this_policy != null)
        {
            return this_policy;
        }

        this._policy = Policy
            .Handle<Exception>()
            .CircuitBreaker(2, TimeSpan.FromMinutes(1));

        return this._policy;
    } 
}

public object Execute(.......)
{
    return Policy.Execute(() => this.hamburgerQuery.GetHamburgers());
}

OR

public object Execute(.......)
{
    var breaker = Policy
            .Handle<Exception>()
            .CircuitBreaker(2, TimeSpan.FromMinutes(1));
    return breaker.Execute(() => this.hamburgerQuery.GetHamburgers());
}

I guess that the first option is the correct way since then the Policy object will always be the same and can keep track of the exception count and stuff like that. My question is, will option number two work as well? I've found a lot of samples/examples on Pollys Github but I can't find any "real world" examples where Polly is used together with DI and stuff like that?

like image 864
JOSEFtw Avatar asked Jun 19 '17 19:06

JOSEFtw


People also ask

Is Polly policy thread safe?

tl;dr; Policy is thread safe, and for the circuit-breaker to work correctly, it must be shared so that you call Execute on the same Policy instance every time!

What is Polly circuit breaker?

Polly is a . NET resilience and transient-fault-handling library that allows developers to express policies such as retry, circuit breaker, timeout, bulkhead isolation, and so forth. It is a mature library that is almost synonymous with app resiliency.

Can I create a Polly policy in a controller?

For more on Polly see www.thepollyproject.org. In that example I created the Polly policy in the constructor of the controller. That of course means it was not reusable, I would have to copy that code into all other controllers that needed the policy, and any policy changes would require me to edit all the controllers.

When you use the Polly circuit-breaker should you share your policies?

When you use the Polly circuit-breaker, make sure you share your Policy instances! This post is somewhat of PSA about using the excellent open source Polly library for handling resiliency to your application.

What is a policy in Salesforce Polly?

A policy basically defines which exceptions to handle, what to do when an exception occurs and you can tell Polly to retry the original method or break and stop the method being called again until a certain timespan has passed. A policy is created using a fluent style interface, so let’s take a look at some simple examples

Why should you avoid singletons in 2016?

In 2016. But it comes up in discussions time and again, so here is a list of reasons why you should avoid singletons. Actually, there’s nothing wrong with having only one instance of an object. But using the “Singleton Pattern” to achieve this is never the best solution.


1 Answers

I guess that the first option is the correct way since then the Policy object will always be the same and can keep track of the exception count and stuff like that.

Correct. This is described in the Polly wiki here. In brief:

  • Share the same breaker policy instance across call sites when you want those call sites to break in common - for instance they have a common downstream dependency.
  • Don't share a breaker instance across call sites when you want those call sites to have independent circuit state and break independently.

See this stackoverflow answer for a more extensive discussion of configuring policies separately from their usage, injecting them to usage sites by DI, and the effects of re-using the same instance (for example a singleton) versus using separate instances, across the full range (at June 2017) of Polly policies.

will option number two work as well?

No (for the converse reason: each call creates a separate instance, so won't share circuit statistics/states with other calls).

like image 71
mountain traveller Avatar answered Oct 21 '22 20:10

mountain traveller