I need to submit a task in an async framework I'm working on, but I need to catch for exceptions, and retry the same task multiple times before "aborting".
The code I'm working with is:
int retries = 0;
public CompletableFuture<Result> executeActionAsync() {
// Execute the action async and get the future
CompletableFuture<Result> f = executeMycustomActionHere();
// If the future completes with exception:
f.exceptionally(ex -> {
retries++; // Increment the retry count
if (retries < MAX_RETRIES)
return executeActionAsync(); // <--- Submit one more time
// Abort with a null value
return null;
});
// Return the future
return f;
}
This currently doesn't compile because the return type of the lambda is wrong: it expects a Result
, but the executeActionAsync
returns a CompletableFuture<Result>
.
How can I implement this fully async retry logic?
Instead of implementing your own retry logic, I recommend using a proven library like failsafe, which has built-in support for futures (and seems more popular than guava-retrying). For your example, it would look something like:
Probably you should avoid
.withFallback(null)
and just have let the returned future's.get()
method throw the resulting exception so the caller of your method can handle it specifically, but that's a design decision you'll have to make.Other things to think about include whether you should retry immediately or wait some period of time between attempts, any sort of recursive backoff (useful when you're calling a web service that might be down), and whether there are specific exceptions that aren't worth retrying (e.g. if the parameters to the method are invalid).
util class:
usage:
output
I recently solved a similar problem using the guava-retrying library.
I think I was successfully. Here's an example class I created and the test code:
RetriableTask.java
Usage
Output
Main idea and some glue code (
failAfter
function) come from here.Any other suggestions or improvement are welcome.
Chaining subsequent retries can be straight-forward:
Read about the drawbacks below
This simply chains as many retries as intended, as these subsequent stages won’t do anything in the non-exceptional case.
One drawback is that if the first attempt fails immediately, so that
f
is already completed exceptionally when the firstexceptionally
handler is chained, the action will be invoked by the calling thread, removing the asynchronous nature of the request entirely. And generally,join()
may block a thread (the default executor will start a new compensation thread then, but still, it’s discouraged). Unfortunately, there is neither, anexceptionallyAsync
or anexceptionallyCompose
method.A solution not invoking
join()
would bedemonstrating how involved combining “compose” and an “exceptionally” handler is.
Further, only the last exception will be reported, if all retries failed. A better solution should report the first exception, with subsequent exceptions of the retries added as suppressed exceptions. Such a solution can be build by chaining a recursive call, as hinted by Gili’s answer, however, in order to use this idea for exception handling, we have to use the steps to combine “compose” and “exceptionally” shown above:
CompletableFuture.failedFuture
is a Java 9 method, but it would be trivial to add a Java 8 compatible backport to your code if needed:Here is an approach that will work for any
CompletionStage
subclass and does not return a dummyCompletableFuture
that does nothing more than wait to get updated by other futures.