Hello! Using Failsafe to help with failures during a database migration. It's been great so far. I am having an issue with listner.getFailure() being null in a fallback policy though. I'm curious if someone could help me out here. Here's my code:
Fallback<String> exceptionFallback = Fallback
.of(
() -> {
System.out.println("Used fallback...");
return "fallback result";
}
)
.handle(Exception.class)
.onFailure(listener -> System.out.println("error " + listener.getFailure()));
String result = Failsafe
.with(exceptionFallback)
.get(
() -> {
throw new RuntimeException("Main exception");
}
);
System.out.println("Result was: " + result);The console output of this is:
Used fallback...
error null
Result was: fallback result I'm very confused why listener.getFailure() is returning null. I'd expect it to be the throwable produced by the runtime exception that I threw. Is that a correct assumption? (using failsafe 2.3.1)
3 replies
Hello,
I am researching retry frameworks, and found Failsafe. It is a great lightweight library.
Would Failsafe be able to handle following use case?
- Upon start up, my service will connect to a data store to retrieve data
- If the connection fails, I would like to connect to a back-up data store and let the service proceed with back-up connection.
- While the back-up connection is in use, I would like to keep retrying to connect to the original data store, and if the connection is successful, replace the back-up connection.
The policy composition handles the execution sequentially. Failsafe.with(fallback, retryPolicy) would retry first, then use the fallback. How to keep retrying while fallback is in use? Or is there any other approach for this use case?
Thanks in advance for your advice
// Stores a reference to the connection to use
AtomicReference<Connection> connectionRef = new AtomicReference<>();
RetryPolicy<Void> retryPolicy = new RetryPolicy<Void>()
.withDelay(Duration.ofSeconds(30))
.handleResult(null);
Fallback<Void> fallback = Fallback.<Void>of(e -> {
if (e.getAttemptCount() == 1)
connectionRef.set(connectToBackup());
}).handleResult(null);
Failsafe.with(retryPolicy, fallback).runAsync(() -> {
connectionRef.set(connectToPrimary());
});@/all
I just moved some things around on the website to hopefully improve the docs:
- The various async related features are now collected on the Async Execution page: https://failsafe.dev/async-execution/
- Per request, I added a comparison with Resilience4j on the comparisons page: https://failsafe.dev/comparisons/#failsafe-vs-resilience4j
As ever, if you like Failsafe, please spread the word. Blogs, social media, etc. are all great.
I just started using failsafe for retries and wonder what's the best approach in my case.
I need 5 threads retrieving webpages from the list in parallel.
I tried using
policy.with(new ForkJoinPool(5)).runAsync(
// retrieve the page
)But if I have thousands of webpages in the list then in case of a failure the threads won't get their slot to retry. I believe the code above creates a thread per page and only five of them can run at the same time.
Hi there
I have the following prepared executor
var fallback = Fallback.ofException(event -> {
log.error(event.getLastFailure().getMessage());
return new CommissionsException(INTEGRATION_EXCEPTION, "Can't perform operation");
});
var retryPolicy = new RetryPolicy<>()
.handle(InvalidTokenException.class, AuthenticationException.class)
.onRetry(event -> tokenManager.refreshToken())
.withMaxRetries(1);
retryExecutor = Failsafe.with(fallback, retryPolicy);and tokenManager.refreshToken() can throw an exception as well, is there a way to handle such exception in the fallback?
for (File zip : zips) {
failsafeExecutor.onSuccess(e -> {
// in here, the zip variable always the first value of zips. When retry successfully I want to update the status, but the "zip" value is not match
log.info("certNo:{}", CcsApiUtil.getCertNo(zip));
setSubmitResult(zip, 0);
}).onFailure(e -> {
log.error("retry 3 times still failure!!");
setSubmitResult(zip, -2);
}).getAsync(context -> CcsApiUtil.uploadFile(zip));
}
@gyudin Yes, by default a RetryPolicy will retry an execution up to two times if any exception is thrown. Else you can configure it to handle other types of failures, which will cause retries as configured:
FYI - Failsafe 3.0 is about to be released. The changelog describes what is coming: https://github.com/failsafe-lib/failsafe/blob/master/CHANGELOG.md#30
Also the website / docs have some updates that will be published after the release: https://github.com/failsafe-lib/failsafe.dev/tree/3.0
@/all Failsafe 3.0 has been released. The website has been updated and the changelog describes what's new:
https://failsafe.dev/
https://github.com/failsafe-lib/failsafe/blob/master/CHANGELOG.md#30
Released 3.2.2, with new OkHttp and Retrofit modules!
@jhalterman ^
Thanks for an amazing library btw!
@jaympatel1893_twitter Hey you're welcome! Yea, onSuccess is called in two cases:
- if the incoming result or exception is not considered a failure by the policy
- if the incoming result or exception is considered a failure by the policy, but the policy handles it successfully
This is mentioned in the docs:
https://failsafe.dev/javadoc/core/dev/failsafe/PolicyListeners.html#onSuccess-dev.failsafe.event.EventListener-
https://failsafe.dev/event-listeners/#determining-success
So in the case of a fallback, that means onSuccess would be called if the fallback doesn't consider the incoming result/exception a failure. Do you think it should work differently or be clarified better in the docs?
Hi!
I've used the (timeout,retrypolicy)-order with the 2.x-version and the wrapping timeout
has successfully terminated the retrying unless success within the timeout.
With 3.x I can't succeed at all with a wrapping timeout (using the builder for both Timeout and retryPolicy).
The retries keep on going forever not taking into account the Timeout. I've tried with a simple method throwing an Exception.
Any hints here...
2.x-code (terminating after 6 secs):
RetryPolicy<Object> objectRetryPolicy = new RetryPolicy<>()
.withDelay(Duration.ofSeconds(1))
.withMaxRetries(-1);
Timeout<Object> timeout = Timeout.of(Duration.ofSeconds(6));
Failsafe.with(timeout,objectRetryPolicy).get(() -> getMe());3.x code (tried to remove "withInterrupt" w/o success)
RetryPolicy<Object> retryPolicy = RetryPolicy.builder()
.withDelay(Duration.ofSeconds(1))
.withMaxRetries(-1)
.build();
Timeout<Object> timeout = Timeout.builder(Duration.ofSeconds(6)).withInterrupt().build();
Failsafe.with(timeout,retryPolicy).get(() -> getMe());However, I note that adding ".withMaxDuration" with the RetryPolicy seems to work as stopper for regular Exceptions.
The timeout seems to work for InterruptedException when used as "leftmost policy" (as in the examples above).
Perhaps I'll switch the policy-order to Failsafe.with(retryPolicy,timeout) and use ".withMaxDuration". Just did some small midnight tests, looks promising.
