Comments (7)
@Spikhalskiy Can you help my understand your use case more for setting a max concurrency in a CircuitBreaker? When max concurrency is reached, you would be ok receiving an exception such as MaxConcurrencyException
?
from failsafe.
@Spikhalskiy Just pushed a change that allows you to limit max concurrency in the half-open state:
new CircuitBreaker()
.withSuccessThreshold(3)
.withMaxConcurrency(1);
Previously, withSuccessThreshold(3)
would allow 3 concurrent executions when in the half-open state. Now we can limit that to 1 via withMaxConcurrency
. We still need 3 successful executions, in this case, in order to close the circuit again, but we can restrict them to occurring one at a time.
Thoughts?
from failsafe.
I think throwing exceptions is a bad idea, especially for a standalone usage. At least it's very expensive.
I would prefer if after concurrency level reaching all methods in the Half Open state would work as for the Open state. Or this behavior could be configurable.
from failsafe.
@Spikhalskiy Thanks - that's actually what it does currently - once max concurrent executions is hit while in half-open state, CircuitOpenException is thrown, which is the same thing that happens when you try an execution in the open state.
from failsafe.
How I need to use this. CircuitBreaker is an underlying structure, which I want to notify about failure or success events, nothing more. After threshold of failure reaches it should be OPEN for configured interval and after than allow 1-2-3 times of service execution. In parallel or one by one, not significant. If it gets failure() for this calls it should put CircuitBreaker back to the Open state for configured interval, if requests are fine - put it to Close state.
from failsafe.
@jhalterman So... for me it's bad behavior that I don't want to see in standalone mode at least.
For example. I have 15 000 requests per second and I have limit for the Half Open state == 1. I would get 14999 exceptions per second only because I probe server right now. Too expensive and it's not an exceptional situation actually, it's just opened (in terms of CircuitBreaker) for now. We are closed for 1 request only and just opened for all others.
Just from my usage point of view.
from failsafe.
@Spikhalskiy Thanks for the info. I think we have 3-4 options when the circuit is in half-open state. We can allow the executions, we can block, we can schedule the executions (if an executor is configured) or we can throw an exception. If we're only allowing 1-3 executions, everything else either needs to block, be scheduled (which might throw an exception if the threadpool is full), or result in an exception. What do you think?
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.