New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Which policies share the state across requests? #494

Closed
vany0114 opened this Issue Aug 30, 2018 · 4 comments

Comments

Projects
None yet
2 participants
@vany0114

vany0114 commented Aug 30, 2018

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?

@reisenberger

This comment has been minimized.

Show comment
Hide comment
@reisenberger

reisenberger Aug 30, 2018

Member

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.

Member

reisenberger commented Aug 30, 2018

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.

@vany0114

This comment has been minimized.

Show comment
Hide comment
@vany0114

vany0114 Aug 30, 2018

Thank you so much for your accurate answer @reisenberger!

vany0114 commented Aug 30, 2018

Thank you so much for your accurate answer @reisenberger!

@reisenberger

This comment has been minimized.

Show comment
Hide comment
@reisenberger

reisenberger Sep 6, 2018

Member

Published a wiki article to cover the topic.

Member

reisenberger commented Sep 6, 2018

Published a wiki article to cover the topic.

@vany0114

This comment has been minimized.

Show comment
Hide comment
@vany0114

vany0114 Sep 6, 2018

@reisenberger Thanks for always improve the documentation!

vany0114 commented Sep 6, 2018

@reisenberger Thanks for always improve the documentation!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment