Comments (9)
@BenRomberg Thanks for filing this. This was indeed a bug where the failed attempt listener would not always be called the final time. For example, with 3 retries as in your example, it might only be called 3 times, not 4 as expected.
onRetry
is a little different though since it only gets called before a retry happens. So with 3 retries it would only be called 3 times, whereas onFailedAttempt
should be called 4 times (since the initial execution failed, plus the 3 retry attempts).
Let me know if that doesn't describe the problem you were having. Also, let me know if you can try the current code in master and if that resolves your issue.
from failsafe.
The problem I had was that the listener was not called at all in the 2 scenarios I described above, even though there were 3 failing retries. Using v0.8.3 btw.
I'll try out master
once I get to it, probably by the end of next week (it's for a side project I only work on Fridays). If it still doesn't work, I'll provide a failing test that highlights the issue. Thanks for the prompt response!
from failsafe.
@BenRomberg I just updated a test case for this issue, and I think it matches the failing scenario you describe:
Right now the test passes. If you do get a chance to come up with a failing test for what you're seeing, that would be great.
from failsafe.
@jhalterman: Finally had the time to try it out. Either it still doesn't work or I'm doing something wrong.
Below are 4 tests that I would expect to pass:
@Test
public void failedAttemptListener_WithFailedResponses_ShouldBeCalled() throws Exception {
@SuppressWarnings("unchecked")
RetryPolicy policy = new RetryPolicy().retryIf((Boolean response) -> response != null && response)
.retryOn(Exception.class).withDelay(1, TimeUnit.SECONDS).withMaxRetries(3);
AtomicInteger listenerCallbacks = new AtomicInteger();
Failsafe.<Response> with(policy)
.onFailedAttempt((failedResponse, exception, context) -> listenerCallbacks.incrementAndGet())
.get(() -> false);
assertThat(listenerCallbacks.get()).isEqualTo(4);
}
@Test
public void retryListener_WithFailedResponses_ShouldBeCalled() throws Exception {
@SuppressWarnings("unchecked")
RetryPolicy policy = new RetryPolicy().retryIf((Boolean response) -> response != null && response)
.retryOn(Exception.class).withDelay(1, TimeUnit.SECONDS).withMaxRetries(3);
AtomicInteger listenerCallbacks = new AtomicInteger();
Failsafe.<Response> with(policy)
.onRetry((failedResponse, exception, context) -> listenerCallbacks.incrementAndGet()).get(() -> false);
assertThat(listenerCallbacks.get()).isEqualTo(3);
}
@Test
public void failedAttemptListener_WithExceptions_ShouldBeCalled() throws Exception {
@SuppressWarnings("unchecked")
RetryPolicy policy = new RetryPolicy().retryIf((Boolean response) -> response != null && response)
.retryOn(Exception.class).withDelay(1, TimeUnit.SECONDS).withMaxRetries(3);
AtomicInteger listenerCallbacks = new AtomicInteger();
try {
Failsafe.<Response> with(policy)
.onFailedAttempt((failedResponse, exception, context) -> listenerCallbacks.incrementAndGet())
.get(() -> {
throw new RuntimeException();
});
} catch (RuntimeException e) {
}
assertThat(listenerCallbacks.get()).isEqualTo(4);
}
@Test
public void retryListener_WithExceptions_ShouldBeCalled() throws Exception {
@SuppressWarnings("unchecked")
RetryPolicy policy = new RetryPolicy().retryIf((Boolean response) -> response != null && response)
.retryOn(Exception.class).withDelay(1, TimeUnit.SECONDS).withMaxRetries(3);
AtomicInteger listenerCallbacks = new AtomicInteger();
try {
Failsafe.<Response> with(policy)
.onRetry((failedResponse, exception, context) -> listenerCallbacks.incrementAndGet()).get(() -> {
throw new RuntimeException();
});
} catch (RuntimeException e) {
}
assertThat(listenerCallbacks.get()).isEqualTo(3);
}
Only the last 2 pass (using either 0.8.3, 0.9.1 or 0.9.2-SNAPSHOT from master
) when the retry is triggered by an exception, but not if it's triggered by an unsatisfying result from the callback (from the retryIf
condition in the policy). As you've used only the retry-on-exception case in your test, it passes, but what I'm talking about is the retryIf
condition not triggering the listener correctly.
from failsafe.
@BenRomberg Thanks for posting this. I think it might just be a problem with the retryIf
statement. Should it be .retryIf((Boolean response) -> response != null && !response)
? We want to retry when response is false
.
from failsafe.
@jhalterman: You're right, I mixed that up. I want it to retry 3 times in the test. But even after changing it, the tests still fail.
from failsafe.
@BenRomberg Do you have any more details on the failure you're seeing? I just added your test cases (without the delay), and they're passing. See ef79e25.
from failsafe.
@jhalterman: I finally figured it out. It was because of the wrong generic type <Response>
I was calling the Failsafe.<Response> with
method with. I changed the types during development and forgot to adjust that one. I think it was necessary in one of the earlier versions of Failsafe, nowadays it's not needed at all and I can just call Failsafe.with(...)
without having to bind an explicit type.
Thanks for your support!
from failsafe.
Actually I just realized that the generic type in Failsafe.with(...)
is still necessary if you need the correct type in the listener callback.
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.