jhalterman on mvn-modules
jhalterman on master
Do not skip staging repo close (compare)
jhalterman on master
[maven-release-plugin] prepare … (compare)
jhalterman on failsafe-parent-3.2.4
jhalterman on master
[maven-release-plugin] prepare … (compare)
jhalterman on master
Update changelog for 3.2.4 (compare)
jhalterman on master
Fix javadoc typo (compare)
jhalterman on master
Synchronize on execution when c… (compare)
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)
Hello,
I am researching retry frameworks, and found Failsafe. It is a great lightweight library.
Would Failsafe be able to handle following use case?
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:
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:
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());