Polly: Using Configuration to Setup Polly

[RehanSaeed]

I've written the following extension method to help me configure Polly from my ASP.NET Core JSON configuration file. It may help others if something more complete was included in Polly itself.

Policy policy = Policy.Handle<Exception>().FromOptions(options);

public class PolicyOptions
{
    public TimeSpan? DurationOfBreak { get; set; }

    public int? ExceptionsAllowedBeforeBreaking { get; set; }

    public int? RetryCount { get; set; }

    public bool RetryForever { get; set; }
}

public static Policy FromOptions(this PolicyBuilder policyBuilder, PolicyOptions options)
{
    if (policyBuilder == null)
    {
        throw new ArgumentNullException(nameof(policyBuilder));
    }

    if (options == null)
    {
        throw new ArgumentNullException(nameof(options));
    }

    Policy policy;
    if (options.RetryCount.HasValue)
    {
        policy = policyBuilder.RetryAsync(options.RetryCount.Value);
    }
    else if (options.RetryForever)
    {
        policy = policyBuilder.RetryForeverAsync();
    }
    else if (options.DurationOfBreak.HasValue && options.ExceptionsAllowedBeforeBreaking.HasValue)
    {
        policy = policyBuilder.CircuitBreakerAsync(options.ExceptionsAllowedBeforeBreaking.Value, options.DurationOfBreak.Value);
    }
    else
    {
        throw new ArgumentException(
            $"Invalid Policy Options.",
            nameof(options));
    }

    return policy;
}

[reisenberger]

@RehanSaeed Thanks for sharing this. There are some similar ideas in issue #50, with discussion around the different aspects of a policy that could be configured (numeric parameters; exceptions handled?); different configuration sources and methods of application; and configuration-only-at-startup versus reconfiguration-during-execution. Please feel free to have a read of #50, and add any further ideas/comments!

[RehanSaeed]

While the two issues talk about config, I feel they are talking about two different kinds of config. That issue is talking about using System.Configuration which should probably exist as a separate NuGet package. What I'm talking about is being able to create a policy based on a POCO with some very simple properties. This POCO can then be used to bind to a JSON config file. This POCO should probably live in the Polly core NuGet package.

[reisenberger]

@RehanSaeed Agreed: if a strategy for configuring policies depends on approaches not part of .NET Core, that would certainly be part of a separate package.

[reisenberger]

_Triage of old issues_:

Configuring policies from lightweight POCOs - or interfaces which group the relevant configuration parameters - remains a possible later addition.

Some initial work can be found in this branch.

The approach is configuration-provider _interfaces_: eg IAdvancedCircuitBreakerConfiguration; IConsecutiveCountCircuitBreakerConfiguration:

• the interfaces can trivially be fulfilled by POCOs
• for .Net Core, in-built .Net Core configuration providers can populate those POCOs
• configuration by interface allows community to implement any other provider they need, eg older System.Configuration.ConfigurationManager requirements
• ~configuration by interface would open a variety of paths to dynamic configuration during running, eg custom providers backed by a database; Dot Net Core's various options for dynamic reconfiguration, etc.~. EDIT Feb 2018: This approach is now deprecated, because it makes policies mutable. We now recommend PolicyRegistry as the route to dynamic reconfiguration during running.

The core Polly package would likely contain only the interfaces and matching flat POCOs. Specific implementations would live in separate Polly.Contrib packages.

_Priority_: Low. Possibly in tandem with any work on refreshed Polly syntax.

_Community contributions welcome_: lower prio for the core Polly maintainers. I can provide guidance if anyone wants to pick up this work.

[reisenberger]

Pinging on this thread, to alert that there is a lot of related discussion going on in the ASP.NET Core 2.1 HttpClientFactory repo around the Polly integration.

[sommmen]

Pinging on this thread, to alert that there is a lot of related discussion going on in the ASP.NET Core 2.1 HttpClientFactory repo around the Polly integration.

Hi - i am a bit confused right now. Im having the same issue as the OP, i am firing a method with polly and i'd like to set the data from appsettings.json. Is there any progress on this or?

[reisenberger]

Thanks @sommmen for the question. There is no extra Options-style POCOs API from the Polly team, but this is very easy to do for yourself along the lines the original poster demonstrated.

[sommmen]

Thanks @sommmen for the question. There is no extra Options-style POCOs API from the Polly team, but this is very easy to do for yourself along the lines the original poster demonstrated.

Hello sir,

Thanks for your reply. Just wanted to make sure I did not reinvent the wheel.

[reisenberger]

_Triage_: Closing this issue as not something the core Polly team is likely to add.

Back when this issue was proposed, it made a lot of sense, as Polly had only two policies, configured in mostly-numeric ways.

Polly now offers a wider range of policies, and a range of more powerful ways of configuring them:

• some policies such as Fallback are entirely non-numeric
• most policies which in their original versions were entirely numeric now also take more function-driven overloads: retry policy can take an IEnumerable<TimeSpan> of delays-before-retrying; or alternatively a Func<outcome, TimeSpan> to drive retry delays from 429 responses; TimeoutPolicy a Func<TimeSpan> timeout; circuit-breaker will soon take a Func<int, TimeSpan> function to calculate breakDuration.

TL;DR A config-constant-driven Options-API for Polly now would inevitably end up covering only a fragmented subset of ways of configuring policies. This makes it make less sense for the Polly team to aim to provide as an API alternative. However, it is still fairly easy for users to implement for themselves (and a great approach), for a particular subset of constant-driven Polly features they use.