Polly: Which policies share the state across requests?

Created on 30 Aug 2018  路  4Comments  路  Source: App-vNext/Polly

Hi,

I would like to know which policies share the state across requests. What I understand is circuit-breaker instances can be shared across multiple call sites, it means if I store the instance, let's say, into a PolicyRegistry, cache, or another storage which hold the object between requests, it keeps the state of the circuit?

For example, my circuit breaker is configured to break the circuit after 3 exceptions, so, I would like that the next incoming requests to that resource fail fast instead to try to execute it. is it possible? also, it applies for Retry as well?

question

Most helpful comment

if I store the [circuit-breaker] instance, let's say, into a PolicyRegistry, cache, or another storage which hold the object between requests, it keeps the state of the circuit?

Yes. CircuitBreakerPolicy instances store the circuit-state internally. The circuit-state is scoped to the policy, and shared across calls.

it applies for Retry as well?

A RetryPolicy instance is reusable across multiple call sites but executions are isolated from each other. Each execution maintains its own retry count independently. The retry state (number of retries) is scoped to the execution, not shared across different calls or call sites.


I would like to know which policies share the state across requests

CircuitBreaker and Bulkhead.

CircuitBreaker's purpose to count and act according to success/fail metrics across calls placed through the policy. It stores those counts in internal state. The intended functional consequence is that if you share a CircuitBreakerPolicy instance in multiple call sites or executions, those call sites or executions will share circuit state.

  • 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.

Bulkhead's purpose is to limit concurrency of calls placed through it. Each single BulkheadPolicy instance tracks that concurrency in internal state. The intended functional consequence is that when you share a BulkheadPolicy instance across call-sites, those call-sites share the bulkhead capacity between them.

  • Share the same BulkheadPolicy instance across multiple call sites when you want call sites to share the bulkhead capacity amongst them.
  • Don't share the same BulkheadPolicy instance across multiple call sites when you want the call sites to have independent bulkhead capacity.

All policies can be stored centrally (eg in a PolicyRegistry) and used at multiple call sites. Only CircuitBreaker and Bulkhead maintain internal state which is shared across calls, bringing the functional effects described above of reusing a single policy instance.

All 4 comments

if I store the [circuit-breaker] instance, let's say, into a PolicyRegistry, cache, or another storage which hold the object between requests, it keeps the state of the circuit?

Yes. CircuitBreakerPolicy instances store the circuit-state internally. The circuit-state is scoped to the policy, and shared across calls.

it applies for Retry as well?

A RetryPolicy instance is reusable across multiple call sites but executions are isolated from each other. Each execution maintains its own retry count independently. The retry state (number of retries) is scoped to the execution, not shared across different calls or call sites.


I would like to know which policies share the state across requests

CircuitBreaker and Bulkhead.

CircuitBreaker's purpose to count and act according to success/fail metrics across calls placed through the policy. It stores those counts in internal state. The intended functional consequence is that if you share a CircuitBreakerPolicy instance in multiple call sites or executions, those call sites or executions will share circuit state.

  • 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.

Bulkhead's purpose is to limit concurrency of calls placed through it. Each single BulkheadPolicy instance tracks that concurrency in internal state. The intended functional consequence is that when you share a BulkheadPolicy instance across call-sites, those call-sites share the bulkhead capacity between them.

  • Share the same BulkheadPolicy instance across multiple call sites when you want call sites to share the bulkhead capacity amongst them.
  • Don't share the same BulkheadPolicy instance across multiple call sites when you want the call sites to have independent bulkhead capacity.

All policies can be stored centrally (eg in a PolicyRegistry) and used at multiple call sites. Only CircuitBreaker and Bulkhead maintain internal state which is shared across calls, bringing the functional effects described above of reusing a single policy instance.

Thank you so much for your accurate answer @reisenberger!

Published a wiki article to cover the topic.

@reisenberger Thanks for always improve the documentation!

Was this page helpful?
0 / 5 - 0 ratings