Comments (11)
Got it.
Composing policies is in theory like composing functions.
That actually pretty much what I'm doing in riptide. We have a Plugin
interface that allows to decorate executions (which are basically just callables). I'm using failsafe for retries and circuit breaker, see riptide-failsafe.
Other plugins provide other functionalities that you also described here or elsewhere:
- timeouts (not per execution, but applied to the outer most decorated function covering any kind of retires/circuit breaker/delay/etc.)
- backup requests, can be thought of as early retries
- metrics, effectively measuring duration of executions
- transient fault detection, basically error handling that can then be used to control retries (using
retryOn
)
from failsafe.
See also #96
from failsafe.
Thinking about this issue some more, I'm not sure that having a circuit breaker before a retry makes sense. Anyone have thoughts on this?
from failsafe.
I'm not sure that having a circuit breaker before a retry makes sense.
Isn't that the current behavior?
from failsafe.
The current behavior is a blend of retry and circuit breaker handling, which I don't think is ideal. I'd like to separate them more clearly so that only one occurs at a time, and so they can be composed in some order.
from failsafe.
Trying out an implementation... will post a PR for review if it looks good.
from failsafe.
See #153 for a discussion topic related to this issue.
from failsafe.
I'm back to this PR and hope to push something to look at soon.
The current Failsafe implementation assumes a specific ordering of policies. Arbitrarily composing synchronous policy executions is straightforward, but composing asynchronous executions is a bit of a challenge. Since async callbacks have no context, we need to re-create the context in which the async execution began, by moving through the composed policies back to the location where the async execution came from before we can continue.
Overall this will be a nice improvement as it unifies a few things internally and will open the door to let policies be more standalone things.
from failsafe.
Since async callbacks have no context, we need to re-create the context in which the async execution began, by moving through the composed policies back to the location where the async execution came from before we can continue.
What kind of context are we talking about exactly?
from failsafe.
What kind of context are we talking about exactly?
The thread/execution context. Composing policies is in theory like composing functions. Given some callable
, we can think of the policies composing around it like:
fallback(retryPolicy(circuitBreaker(callable)))
If the callable
is synchronous, this composition is simple and works as expected. If it's asynchronous, the callable
is executed on a separate thread, and when it's done we're no longer nested within the other policies. So we have to re-create that nesting before we can handle the callable's result.
The way we do this is treating the composition like a chain. To first execute the callable
we work our way along the chain and call the callable on a separate thread:
fallback -> retryPolicy -> circuitBreaker -> callable.callAsync
Since the result of the callable comes to us on a separate thread without any context, we have to re-create the context by working our way back down the chain to where we triggered the async call, then we can handle the result synchronously as we normally would:
fallback -> retryPolicy -> circuitBreaker.handleResult(result)
fallback -> retryPolicy.handleResult(result)
fallback.handleResult(result)
This isn't the best explanation, but hope it conveys the idea.
from failsafe.
Fixed by 5d919d5. The sync and async implementations of the problem described above are here.
from failsafe.
Related Issues (20)
- Why does CheckedPredicate exist? HOT 2
- Also add note about default maxRetries of 3 to maxDuration section of the documentation HOT 7
- Bulkhead policy may drop requests when maxWaitTime is specified HOT 8
- Guidance around CheckedPredicate HOT 2
- Time based error limiter policy
- [Question]Can withBackoff and withDelay be used at the same time? HOT 2
- RetryPolicy handleIf not working with DynamoDbException in predicate HOT 4
- Having a context object in the run(...) and get(...) methods HOT 7
- dev.failsafe.Functions.* do not propagate toString to the wrapped object
- [Question] Is it possible to have multiple Fallback policies in one Failsafe executor? HOT 4
- [question] how to use failsafe with kotlin
- Feature Request: Integrate / add support for Lunar Proxy (backend policy) HOT 1
- Why recommend CircuitBreaker before Retry? HOT 1
- CircuitBreaker stays in OPEN even after DELAY time HOT 1
- Nested retries, how to prevent duplicate retrying? HOT 5
- FailsafeExecutor.compose and .with(Executor) have surprising composition behavior
- Provide BOM with all failsafe artifacts for better dependency management
- Failsafe okhttp integration causes issues with BearerAuth and outdated tokens
- CircuitBreakerBuilder withSuccessThreshold documentation whoopsy HOT 1
- [Question] Is it possible to override the "maxRetries" and "delay" of retry policy at runtime? HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from failsafe.