Understanding the semantics of Polly policies when canceling a policy definition from execution
With Polly, I would like my definition of a policy and the implementation of this policy in two different statements, for example:
// Policy definition
var policy = Policy
.HandleResult<IRestResponse>(predicate)
.Retry(2);
// Policy execution
policy.ExecuteAndCapture(() =>
{
DoSomethingAndReturnAnIRestResponse();
};
I want to do it in such a way that I can better use my retry policies for example. for use in dependency injection.
I'm trying to figure out if there are any considerations when splitting policy and executing in this way, for example if there is any "state" (for lack of a better term) that might not carry over into policy
an object from policy definition to execution.
In these lines, I notice that when I use Polly ExecuteAndCapture()
above, some properties (related to catching trailing exception / result related ExecuteAndCapture()
) are not mapped to the policy
object. According to the documentation ( here and here ), after completing a policy such as:
var policy = Policy
.HandleResult<IRestResponse>(predicate)
.Retry(2)
.ExecuteAndCapture(() =>
{
DoSomethingAndReturnAnIRestResponse();
});
... you should return:
PolicyResult.Outcome
PolicyResult.FinalException
PolicyResult.ExceptionType
PolicyResult.Result
It really happens, then it ExecuteAndCapture()
is in the same expression as the definition of policy. However, when you cancel the policy definition from execution, these properties are not available. I naively assumed they would appear on an existing object policy
, but they don't:
It seems I need to create a new variable assignment to access these properties:
Are there any problems here?
source to share
No problems. Configuring policies other than their use and injecting them into use sites is a common scheme that we use extensively in production.
All Polly policies are thread safe and can be used concurrently across multiple independent sites.
Two kinds of Polly policy - to safely maintain internal state between calls, to perform its designed functions. This leads to specific (intended) effects if you share these policy instances across call sites.
CircuitBreaker
/AdvancedCircuitBreaker
raison-detre - Calculate and act according to success / failure labels between calls placed under the policy. Each individual instance of a policy retains this state internally for itself.
The functional implication of this is that if you share an instance CircuitBreakerPolicy
across multiple call sites, those multiple address sites will share schema state, as discussed here .
- Share the same instance of the interrupt policy between call sites if you want these call sites to be common — for example, they have a common downstream dependency.
- Do not use an interrupt instance across all sites if you want those call sites to have independent rung state and are independent of each other.
Bulkhead
raison-detre should limit the concurrency of calls placed through it. Each individual instance BulkheadPolicy
maintains an internal state to keep track of this.
The functional result (intended) is that when an instance is shared BulkheadPolicy
across all call sites, these member sites share the bulkhead bandwidth between them.
- Share the same instance
BulkheadPolicy
across multiple sites if you want the calling sites to share the bulkhead capacity between them. - Don't use the same instance
BulkheadPolicy
across multiple sites if you want them to have independent bandwidth.
No other Polly policy maintains the internal state of a policy instance across all executions.
.ExecuteAndCapture(...)
The result of the call is .ExecuteAndCapture(...)
not relevant policy
in any of the cases in question. In both cases (definition and execution in the same expression or separation) the result of the call.ExecuteAndCapture(...)
is a new PolicyResult
instance.
Each execution returns a new instance PolicyResult
. PolicyResult
never saved as the state of the policy instance (this makes the policy insecure and reusable across all sites).
Change var
to the actual type ( policy
or PolicyResult
) at each place in the code and this may be clearer.
source to share