Java retry on error

Неблокирующий повтор (retry) в Java и проект Loom

Введение

Повтор (retry) операции является старейшим механизмом обеспечения надежности программного обеспечения. Мы используем повторы при выполнении HTTP запросов, запросов к базам данных, отсылке электронной почты и проч. и проч.

Наивный повтор

Если Вы программировали, то наверняка писали процедуру какого либо повтора. Простейший повтор использует цикл с некоторым ожиданием после неудачной попытки. Примерно вот так.

Вот пример использования повтора для получения соединения к базе данных. Мы делаем 10 попыток с задержкой 100 msec.

Этот код блокирует Ваш поток на одну секунду (точнее 900 milliseconds, мы не ждем после последней попытки) потому что Thread.sleep() является блокирующей операцией. Попробуем оценить производительность метода в терминах количества потоков (threads) и времени. Предположим нам нужно сделать 12 операций повтора. Нам потребуется 12 потоков чтобы выполнить задуманное за минимальное время 1 сек, 6 потоков выполнят повторы на 2 сек, 4 — за три секунды, один поток — за 12 секунд. А что если нам потребуется выполнить 1000 операций повтора? Для быстрого выполнения потребуется 1000 потоков (нет, только не это) или 16 минут в одном потоке. Как мы видим этот метод плохо масштабируется.

Давайте проверим это на тесте

Теоретически: 900 ms * 3 = 2.7 sec, хорошее совпадение

Неблокирующий повтор

А можно ли делать повторы не блокируя потоки? Можно, если вместо Thread.sleep() использовать перепланирование потока на некоторый момент в будущем при помощи CompletableFuture.delayedExecutor() . Как это сделать можно посмотреть в моем классе Retry.java . Кстати подобный подход используется в неблокирующем методе delay() в Kotlin.

Retry.java — компактный класс без внешних зависимостей который может делать неблокирующий асинхронный повтор операции ( исходный код, Javadoc ).
Полное описание возможностей Retry с примерами можно посмотреть тут

Так можно сделать повтор, который мы уже делали выше.

Мы видим что здесь возвращается не Connection , а CompletableFuture , что говорит об асинхронной природе этого вызова. Давайте попробуем выполнить 1000 повторов в одном потоке при помощи Retry .

Как мы видим, Retry не блокируется и выполняет 1000 повторов в одном потоке чуть-чуть более одной секунды. Ура, мы можем эффективно делать повторы.

Причем здесь проект Loom?

Проект Loom добавляет в JDK 19 виртуальные потоки (пока в стадии preview). Цель введения виртуальных потоков лучше всего описана в JEP 425 и я рекомендую это к прочтению.

Возвращаясь к нашей теме повтора операций, коротко скажу что Thread.sleep() более не является блокирующей операцией будучи выполняемой в виртуальном потоке. Точнее говоря, sleep() приостановит (suspend) виртуальный поток, давая возможность системному потоку (carrier thread) переключиться на выполнение других виртуальных потоков. После истечения срока сна, виртуальный поток возобновит (resume) свою работу. Давайте запустим наивный алгоритм повтора в виртуальных потоках.

Поразительно, имеем чуть более одной секунды на 1000 повторов, как и при использовании Retry .

Проект Loom принесет кардинальные изменения в экосистему Java.

Стиль виртуальный поток на запрос (thread per request) масштабируется с почти оптимальным использованием процессорных ядер. Этот стиль становится рекомендуемым.

Виртуальные потоки не усложняют модель программирования и не требуют изучения новых концепций, автор JEP 425 говорит что скорее нужно будет забыть старые привычки («it may require unlearning habits developed to cope with today’s high cost of threads.»)

Многие стандартные библиотеки модифицированы для совместной работы с виртуальными потоками.Так например, блокирующие операции чтения из сокета станут неблокирующими в виртуальном потоке.

Реактивный/асинхронный стиль программирования становится практически не нужным.

Нас ждут интересные времена в ближайшем будущем. Я очень надеюсь что виртуальные потоки станут стандартной частью JDK в очередной LTS версии Java.

Источник

spring-projects/spring-retry

Use Git or checkout with SVN using the web URL.

Work fast with our official CLI. Learn more.

Sign In Required

Please sign in to use Codespaces.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching Xcode

If nothing happens, download Xcode and try again.

Launching Visual Studio Code

Your codespace will open once ready.

There was a problem preparing your codespace, please try again.

Latest commit

Git stats

Files

Failed to load latest commit information.

README.md

This project provides declarative retry support for Spring applications. It is used in Spring Batch, Spring Integration, and others. Imperative retry is also supported for explicit usage.

This section provides a quick introduction to getting started with Spring Retry. It includes a declarative example and an imperative example.

The following example shows how to use Spring Retry in its declarative style:

This example calls the service method and, if it fails with a RemoteAccessException , retries (by default, up to three times), and then tries the recover method if unsuccessful. There are various options in the @Retryable annotation attributes for including and excluding exception types, limiting the number of retries, and setting the policy for backoff.

The declarative approach to applying retry handling by using the @Retryable annotation shown earlier has an additional runtime dependency on AOP classes. For details on how to resolve this dependency in your project, see the ‘Java Configuration for Retry Proxies’ section.

The following example shows how to use Spring Retry in its imperative style (available since version 1.3):

For versions prior to 1.3, see the examples in the RetryTemplate section.

Spring Retry requires Java 1.7 and Maven 3.0.5 (or greater). To build, run the following Maven command:

Features and API

This section discusses the features of Spring Retry and shows how to use its API.

To make processing more robust and less prone to failure, it sometimes helps to automatically retry a failed operation, in case it might succeed on a subsequent attempt. Errors that are susceptible to this kind of treatment are transient in nature. For example, a remote call to a web service or an RMI service that fails because of a network glitch or a DeadLockLoserException in a database update may resolve itself after a short wait. To automate the retry of such operations, Spring Retry has the RetryOperations strategy. The RetryOperations interface definition follows:

The basic callback is a simple interface that lets you insert some business logic to be retried:

The callback is tried, and, if it fails (by throwing an Exception ), it is retried until either it is successful or the implementation decides to abort. There are a number of overloaded execute methods in the RetryOperations interface, to deal with various use cases for recovery when all retry attempts are exhausted and to deal with retry state, which lets clients and implementations store information between calls (more on this later).

The simplest general purpose implementation of RetryOperations is RetryTemplate . The following example shows how to use it:

In the preceding example, we execute a web service call and return the result to the user. If that call fails, it is retried until a timeout is reached.

Since version 1.3, fluent configuration of RetryTemplate is also available, as follows:

The method parameter for the RetryCallback is a RetryContext . Many callbacks ignore the context. However, if necessary, you can use it as an attribute bag to store data for the duration of the iteration.

A RetryContext has a parent context if there is a nested retry in progress in the same thread. The parent context is occasionally useful for storing data that needs to be shared between calls to execute.

When a retry is exhausted, the RetryOperations can pass control to a different callback: RecoveryCallback . To use this feature, clients can pass in the callbacks together to the same method, as the following example shows:

If the business logic does not succeed before the template decides to abort, the client is given the chance to do some alternate processing through the recovery callback.

In the simplest case, a retry is just a while loop: the RetryTemplate can keep trying until it either succeeds or fails. The RetryContext contains some state to determine whether to retry or abort. However, this state is on the stack, and there is no need to store it anywhere globally. Consequently, we call this «stateless retry». The distinction between stateless and stateful retry is contained in the implementation of RetryPolicy ( RetryTemplate can handle both). In a stateless retry, the callback is always executed in the same thread as when it failed on retry.

Where the failure has caused a transactional resource to become invalid, there are some special considerations. This does not apply to a simple remote call, because there is (usually) no transactional resource, but it does sometimes apply to a database update, especially when using Hibernate. In this case, it only makes sense to rethrow the exception that called the failure immediately so that the transaction can roll back and we can start a new (and valid) one.

In these cases, a stateless retry is not good enough, because the re-throw and roll back necessarily involve leaving the RetryOperations.execute() method and potentially losing the context that was on the stack. To avoid losing the context, we have to introduce a storage strategy to lift it off the stack and put it (at a minimum) in heap storage. For this purpose, Spring Retry provides a storage strategy called RetryContextCache , which you can inject into the RetryTemplate . The default implementation of the RetryContextCache is in-memory, using a simple Map . It has a strictly enforced maximum capacity, to avoid memory leaks, but it does not have any advanced cache features (such as time to live). You should consider injecting a Map that has those features if you need them. For advanced usage with multiple processes in a clustered environment, you might also consider implementing the RetryContextCache with a cluster cache of some sort (though, even in a clustered environment, this might be overkill).

Part of the responsibility of the RetryOperations is to recognize the failed operations when they come back in a new execution (and usually wrapped in a new transaction). To facilitate this, Spring Retry provides the RetryState abstraction. This works in conjunction with special execute methods in the RetryOperations .

The failed operations are recognized by identifying the state across multiple invocations of the retry. To identify the state, you can provide a RetryState object that is responsible for returning a unique key that identifies the item. The identifier is used as a key in the RetryContextCache .

Warning: Be very careful with the implementation of Object.equals() and Object.hashCode() in the key returned by RetryState . The best advice is to use a business key to identify the items. In the case of a JMS message, you can use the message ID.

When the retry is exhausted, you also have the option to handle the failed item in a different way, instead of calling the RetryCallback (which is now presumed to be likely to fail). As in the stateless case, this option is provided by the RecoveryCallback , which you can provide by passing it in to the execute method of RetryOperations .

The decision to retry or not is actually delegated to a regular RetryPolicy , so the usual concerns about limits and timeouts can be injected there (see the Additional Dependencies section).

Inside a RetryTemplate , the decision to retry or fail in the execute method is determined by a RetryPolicy , which is also a factory for the RetryContext . The RetryTemplate is responsible for using the current policy to create a RetryContext and passing that in to the RetryCallback at every attempt. After a callback fails, the RetryTemplate has to make a call to the RetryPolicy to ask it to update its state (which is stored in RetryContext ). It then asks the policy if another attempt can be made. If another attempt cannot be made (for example, because a limit has been reached or a timeout has been detected), the policy is also responsible for identifying the exhausted state — but not for handling the exception. RetryTemplate throws the original exception, except in the stateful case, when no recovery is available. In that case, it throws RetryExhaustedException . You can also set a flag in the RetryTemplate to have it unconditionally throw the original exception from the callback (that is, from user code) instead.

Tip: Failures are inherently either retryable or not — if the same exception is always going to be thrown from the business logic, it does not help to retry it. So you should not retry on all exception types. Rather, try to focus on only those exceptions that you expect to be retryable. It is not usually harmful to the business logic to retry more aggressively, but it is wasteful, because, if a failure is deterministic, time is spent retrying something that you know in advance is fatal.

Spring Retry provides some simple general-purpose implementations of stateless RetryPolicy (for example, a SimpleRetryPolicy ) and the TimeoutRetryPolicy used in the preceding example.

The SimpleRetryPolicy allows a retry on any of a named list of exception types, up to a fixed number of times. The following example shows how to use it:

A more flexible implementation called ExceptionClassifierRetryPolicy is also available. It lets you configure different retry behavior for an arbitrary set of exception types through the ExceptionClassifier abstraction. The policy works by calling on the classifier to convert an exception into a delegate RetryPolicy . For example, one exception type can be retried more times before failure than another, by mapping it to a different policy.

You might need to implement your own retry policies for more customized decisions. For instance, if there is a well-known, solution-specific, classification of exceptions into retryable and not retryable.

When retrying after a transient failure, it often helps to wait a bit before trying again, because (usually) the failure is caused by some problem that can be resolved only by waiting. If a RetryCallback fails, the RetryTemplate can pause execution according to the BackoffPolicy . The following listing shows the definition of the BackoffPolicy interface:

A BackoffPolicy is free to implement the backoff in any way it chooses. The policies provided by Spring Retry all use Object.wait() . A common use case is to back off with an exponentially increasing wait period, to avoid two retries getting into lock step and both failing (a lesson learned from Ethernet). For this purpose, Spring Retry provides ExponentialBackoffPolicy . Spring Retry also provides randomized versions of delay policies that are quite useful to avoid resonating between related failures in a complex system.

It is often useful to be able to receive additional callbacks for cross cutting concerns across a number of different retries. For this purpose, Spring Retry provides the RetryListener interface. The RetryTemplate lets you register RetryListener instances, and they are given callbacks with the RetryContext and Throwable (where available during the iteration).

The following listing shows the RetryListener interface:

The open and close callbacks come before and after the entire retry in the simplest case, and onSuccess , onError apply to the individual RetryCallback calls; the current retry count can be obtained from the RetryContext . The close method might also receive a Throwable . Starting with version 2.0, the onSuccess method is called after a successful call to the callback. This allows the listener to examine the result and throw an exception if the result doesn’t match some expected criteria. The type of the exception thrown is then used to determine whether the call should be retried or not, based on the retry policy. If there has been an error, it is the last one thrown by the RetryCallback .

Note that when there is more than one listener, they are in a list, so there is an order. In this case, open is called in the same order, while onSuccess , onError , and close are called in reverse order.

Listeners for Reflective Method Invocations

When dealing with methods that are annotated with @Retryable or with Spring AOP intercepted methods, Spring Retry allows a detailed inspection of the method invocation within the RetryListener implementation.

Such a scenario could be particularly useful when there is a need to monitor how often a certain method call has been retried and expose it with detailed tagging information (such as class name, method name, or even parameter values in some exotic cases).

Starting with version 2.0, the MethodInvocationRetryListenerSupport has a new method doOnSuccess .

The following example registers such a listener:

Sometimes, you want to retry some business processing every time it happens. The classic example of this is the remote service call. Spring Retry provides an AOP interceptor that wraps a method call in a RetryOperations instance for exactly this purpose. The RetryOperationsInterceptor executes the intercepted method and retries on failure according to the RetryPolicy in the provided RepeatTemplate .

Java Configuration for Retry Proxies

You can add the @EnableRetry annotation to one of your @Configuration classes and use @Retryable on the methods (or on the type level for all methods) that you want to retry. You can also specify any number of retry listeners. The following example shows how to do so:

You can use the attributes of @Retryable to control the RetryPolicy and BackoffPolicy , as follows:

The preceding example creates a random backoff between 100 and 500 milliseconds and up to 12 attempts. There is also a stateful attribute (default: false ) to control whether the retry is stateful or not. To use stateful retry, the intercepted method has to have arguments, since they are used to construct the cache key for the state.

The @EnableRetry annotation also looks for beans of type Sleeper and other strategies used in the RetryTemplate and interceptors to control the behavior of the retry at runtime.

The @EnableRetry annotation creates proxies for @Retryable beans, and the proxies (that is, the bean instances in the application) have the Retryable interface added to them. This is purely a marker interface, but it might be useful for other tools looking to apply retry advice (they should usually not bother if the bean already implements Retryable ).

If you want to take an alternative code path when the retry is exhausted, you can supply a recovery method. Methods should be declared in the same class as the @Retryable instance and marked @Recover . The return type must match the @Retryable method. The arguments for the recovery method can optionally include the exception that was thrown and (optionally) the arguments passed to the original retryable method (or a partial list of them as long as none are omitted up to the last one needed). The following example shows how to do so:

To resolve conflicts between multiple methods that can be picked for recovery, you can explicitly specify recovery method name. The following example shows how to do so:

Version 1.3.2 and later supports matching a parameterized (generic) return type to detect the correct recovery method:

Version 1.2 introduced the ability to use expressions for certain properties. The following example show how to use expressions this way:

Since Spring Retry 1.2.5, for exceptionExpression , templated expressions ( # <. >) are deprecated in favor of simple expression strings ( message.contains(‘this can be retried’) ).

Expressions can contain property placeholders, such as #<$> or #<@exceptionChecker.$(#root)> . The following rules apply:

• exceptionExpression is evaluated against the thrown exception as the #root object.
• maxAttemptsExpression and the @BackOff expression attributes are evaluated once, during initialization. There is no root object for the evaluation but they can reference other beans in the context

Starting with version 2.0, expressions in @Retryable , @CircuitBreaker , and BackOff can be evaluated once, during application initialization, or at runtime. With earlier versions, evaluation was always performed during initialization (except for Retryable.exceptionExpression which is always evaluated at runtime). When evaluating at runtime, a root object containing the method arguments is passed to the evaluation context.

Note: The arguments are not available until the method has been called at least once; they will be null initially, which means, for example, you can’t set the initial maxAttempts using an argument value, you can, however, change the maxAttempts after the first failure and before any retries are performed. Also, the arguments are only available when using stateless retry (which includes the @CircuitBreaker ).

Version 2.0 adds more flexibility to exception classification.

retryFor and noRetryFor are replacements of include and exclude properties, which are now deprecated. The new notRecoverable property allows the recovery method(s) to be skipped, even if one matches the exception type; the exception is thrown to the caller either after retries are exhausted, or immediately, if the exception is not retryable.

Where runtimeConfigs is a bean with those properties.

The declarative approach to applying retry handling by using the @Retryable annotation shown earlier has an additional runtime dependency on AOP classes that need to be declared in your project. If your application is implemented by using Spring Boot, this dependency is best resolved by using the Spring Boot starter for AOP. For example, for Gradle, add the following line to your build.gradle file:

For non-Boot apps, you need to declare a runtime dependency on the latest version of AspectJ’s aspectjweaver module. For example, for Gradle, you should add the following line to your build.gradle file:

Starting from version 1.3.2 and later @Retryable annotation can be used in custom composed annotations to create your own annotations with predefined behaviour. For example if you discover you need two kinds of retry strategy, one for local services calls, and one for remote services calls, you could decide to create two custom annotations @LocalRetryable and @RemoteRetryable that differs in the retry strategy as well in the maximum number of retries.

To make custom annotation composition work properly you can use @AliasFor annotation, for example on the recover method, so that you can further extend the versatility of your custom annotations and allow the recover argument value to be picked up as if it was set on the recover method of the base @Retryable annotation.

The following example of declarative iteration uses Spring AOP to repeat a service call to a method called remoteCall :

For more detail on how to configure AOP interceptors, see the Spring Framework Documentation.

The preceding example uses a default RetryTemplate inside the interceptor. To change the policies or listeners, you need only inject an instance of RetryTemplate into the interceptor.

Spring Retry is released under the non-restrictive Apache 2.0 license and follows a very standard Github development process, using Github tracker for issues and merging pull requests into the main branch. If you want to contribute even something trivial, please do not hesitate, but do please follow the guidelines in the next paragraph.

Before we can accept a non-trivial patch or pull request, we need you to sign the contributor’s agreement. Signing the contributor’s agreement does not grant anyone commit rights to the main repository, but it does mean that we can accept your contributions, and you will get an author credit if we do. Active contributors might be asked to join the core team and be given the ability to merge pull requests.

Источник

This post will discuss how to implement retry logic in Java.

1. Simple for-loop with try-catch

A simple solution to implement retry logic in Java is to write your code inside a for loop that executes the specified number of times (the maximum retry value).

The following program demonstrates this. Note that the code is enclosed within a try-catch and if an exception happens inside the try block, the control goes to the catch block. After handling the exception, the system runs the code again after 1 second. After all retries are exhausted and the last re-try fails, the system throws an exception.

Download  Run Code

Output (will vary):

Random number is.. 0
/ by zero
Random number is.. 0
/ by zero
Random number is.. 1

2. Using Interface

We can easily tweak the above logic to isolate the task logic with the retry logic using an interface. The following code demonstrates this.

Download  Run Code

Output (will vary):

Random number is.. 0
/ by zero
Random number is.. 0
/ by zero
Random number is.. 0
/ by zero
Random number is.. 1

3. Third-party libraries

If your project is up for using third-party libraries, we recommend using the following libraries that has strong support for retry logic in Java.

1. Failsafe

Failsafe is a lightweight, zero-dependency library for handling failures in Java 8+. Failsafe works by wrapping executable logic with one or more resilience policies, which can be combined and composed as needed.

To start, create a retry policy that defines which failures should be handled and when retries should be performed:

 
Then you can execute a Runnable or Supplier with retries:

 
Read more – Failsafe Documentation

2. Guava-retrying

The guava-retrying module provides a general purpose method for retrying arbitrary Java code with specific stop, retry, and exception handling capabilities that are enhanced by Guava’s predicate matching.

The minimal sample of some of the functionality would look like:

 
This will retry whenever the result of the Callable is null, if an IOException is thrown, or if any other RuntimeException is thrown from the call() method. It will stop after attempting to retry 3 times and throw a RetryException that contains information about the last failed attempt. If any other Exception pops out of the call() method it’s wrapped and rethrown in an ExecutionException.

Read more – Guava-retrying Documentation

That’s all about implemeting retry logic in Java.

In this post, we are covering the Spring Retry feature. This feature is handy when we are integrating with external API’s and need a robust system to handle system downtime or network downtime.

Introduction

To make processing more robust and less prone to failure, sometimes it helps to automatically retry a failed operation in case it might succeed on a subsequent attempt. Let’s take an example of external API integration where web service call may fail because of a network failure or network glitch. Retry provides the ability to automatically re-invoke a failed operation. In this post, we will learn how to use Spring retry feature in a Spring application.

1. Project Setup

To enable support to the Spring Retry, add following dependencies in your pom.xml file 

<dependency>
   <groupId>org.springframework.retry</groupId>
   <artifactId>spring-retry</artifactId>
   <version>1.2.2.RELEASE</version>
</dependency>

Please check maven central for the latest artifact. Spring Retry also require AOP. For Spring Boot, add the spring-boot-starter-aop starter in the pom.xml.

<dependency>
   <groupId>org.springframework.boot</groupId>
   <artifactId>spring-boot-starter-aop</artifactId>
</dependency>

[pullquote align=”normal”]We are using Spring Boot for this post. [/pullquote]

In case you are not using Spring Boot, add following dependencies in your pom.xml.

<dependency>
   <groupId>org.springframework</groupId>
   <artifactId>spring-aop</artifactId>
   <version>5.0.8.RELEASE</version>
</dependency>
<dependency>
   <groupId>org.aspectj</groupId>
   <artifactId>aspectjweaver</artifactId>
   <version>1.9.1</version>
</dependency>

2. Enable Spring Retry

Add @EnableRetry annotation to the configuration class.

@EnableRetry
@SpringBootApplication
public class SpringBootApplication {
 // ...
}

For non Spring Boot applications

@Configuration
@EnableRetry
public class Application {
 // ...
}

2. @Retryable Annotation

As the next step to use the retry feature, we use @Retryable annotation on the method where we like to enable retry feature.

2.1 @Retryable

Let’s create our sample retry service to see @Retryable annotation in action.

package com.javadevjournal.service;

import com.javadevjournal.exception.CustomException;
import com.javadevjournal.exception.CustomRetryException;
import org.springframework.retry.annotation.Backoff;
import org.springframework.retry.annotation.EnableRetry;
import org.springframework.retry.annotation.Retryable;

public interface RetryService {

 @Retryable(value = {
  CustomRetryException.class}, maxAttempts = 4, backoff = @Backoff(200))
  public String retry() throws CustomRetryException, CustomException;
}

@Retryable annotation provides options to customize the retry behavior. Here are the details.

• value attribute tells Spring retry to act if the method throws CustomRetryException or CustomException.
• maxAttempts set the maximum number of retry. If you do not specify the default value is 3.
• backoff specify the delay in the next retry. The default value is 1 second.

2.2 @Recover

The @Recover annotation used to define a separate recovery method when a @Retryablemethod fails with a specified exception.

import com.javadevjournal.exception.CustomException;
import com.javadevjournal.exception.CustomRetryException;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.stereotype.Service;

@Service
public class DefaultRetryService implements RetryService {

 private static final Logger LOG = LoggerFactory.getLogger(DefaultRetryService.class);
 private static int count = 0;

 @Override
 public String retry() throws CustomRetryException {
  LOG.info("Throwing CustomRetryException in method retry");
  throw new CustomRetryException("Throw custom exception");
 }

 @Override
 @Recover
 public String recover(Throwable throwable) {
  LOG.info("Default Retry servive test");
  return "Error Class :: " + throwable.getClass().getName();
 }
}

2.3 Testing Application

Let’s run our application to see the output

package com.javadevjournal;

import com.javadevjournal.exception.CustomException;
import com.javadevjournal.exception.CustomRetryException;
import com.javadevjournal.service.RetryService;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;
import org.springframework.test.context.junit4.SpringRunner;

@RunWith(SpringJUnit4ClassRunner.class)
@SpringBootTest
public class SpringRetryApplicationTests {

 private static final Logger LOGGER = LoggerFactory.getLogger(SpringRetryApplicationTests.class);

 @Autowired
 RetryService retryService;

 @Test
 public void contextLoads() {}

 @Test
 public void sampleRetryService() {
  try {
   final String message = retryService.retry();
   LOGGER.info("message = " + message);
  } catch (CustomRetryException e) {
   LOGGER.error("Error while executing test {}", e.getMessage());
  }
 }
}

We have the following output on the console

2018-09-02 21:45:10.059  INFO 55106 --- [           main] c.j.service.DefaultRetryService          : Counter current value is 1 
2018-09-02 21:45:10.059  INFO 55106 --- [           main] c.j.service.DefaultRetryService          : CustomRetryException
2018-09-02 21:45:10.262  INFO 55106 --- [           main] c.j.service.DefaultRetryService          : Counter current value is 2 
2018-09-02 21:45:10.262  INFO 55106 --- [           main] c.j.service.DefaultRetryService          : CustomException
2018-09-02 21:45:10.462  INFO 55106 --- [           main] c.j.service.DefaultRetryService          : Counter current value is 3 
2018-09-02 21:45:10.463  INFO 55106 --- [           main] c.j.service.DefaultRetryService          : Default Retry servive test
2018-09-02 21:45:10.463  INFO 55106 --- [           main] c.j.SpringRetryApplicationTests          : message = Error Class :: java.lang.RuntimeException

3. RetryTemplate

RetryTemplate provides alternate in a case using the retry annotation is not an option for you.

3.1 RetryOperations

Spring retry providesRetryOperations strategy using RetryOperations interface. This interface provides several execute() methods.

public interface RetryOperations {

 <T> T execute(RetryCallback < T > retryCallback) throws Exception;
 // other execute methods

 <T> T execute(RetryCallback < T > retryCallback, RecoveryCallback < T > recoveryCallback,
  RetryState retryState) throws Exception;
}

The RetryCallback allows insertion of business logic that needs to be retried upon failure.

public interface RetryCallback <T> {
T doWithRetry(RetryContext context) throws Throwable;
}

3.2 RetryTemplate

The RetryTemplate provides an implementation for the RetryOperations.It is considered a good practice to create a bean from it.

@Configuration
public class ApplicationConfiguration {

 public RetryTemplate retryTemplate() {
  SimpleRetryPolicy simpleRetryPolicy = new SimpleRetryPolicy();
  simpleRetryPolicy.setMaxAttempts(2);

  FixedBackOffPolicy backOffPolicy = new FixedBackOffPolicy();
  backOffPolicy.setBackOffPeriod(1000 L); // milliseconds

  RetryTemplate template = new RetryTemplate();
  template.setRetryPolicy(simpleRetryPolicy);
  template.setBackOffPolicy(backOffPolicy);

  return template;
 }
}

3.3  Testing RetryTemplate

@RunWith(SpringJUnit4ClassRunner.class)
@SpringBootTest
public class SpringRetryApplicationTests {

 private static final Logger LOGGER = LoggerFactory.getLogger(SpringRetryApplicationTests.class);

 @Autowired
 RetryService retryService;

 @Autowired
 RetryTemplate retryTemplate;

 @Test
 public void contextLoads() {}


 @Test(expected = RuntimeException.class)
 public void retryTemplateTest() {
  retryTemplate.execute(args -> {
   retryService.templateRetryService();
   return null;
  });
 }
}

4. When to use Spring Retry

Spring retry is a powerful and robust feature, however, this is not a solution for all the problems. Let’s have a look at some use cases where a retry is not the best option.

• Use retry only on the temporary errors. I do not recommend it to use it on permanent errors else it can cause system performance issues.
• Spring retry is not an alternative to circuit breaker concept. It may be a good idea to mix both retry and circuit breaker feature.

Summary

In this post, we looked at the different features of Spring retry. We got better clarity how it can help us make our applications more robust. We learned how to use @Retryable annotations and the RetryTemplate.

Decide whether to proceed with the ongoing retry attempt.

Clean up the cache if necessary and close the context provided (if the flag
indicates that processing was successful).

Execute the callback once if the policy dictates that we can, otherwise execute the
recovery callback.

Keep executing the callback until it either succeeds or the policy dictates that we
stop, in which case the most recent exception thrown by the callback will be
rethrown.

Keep executing the callback until it either succeeds or the policy dictates that we
stop, in which case the recovery callback will be executed.

Execute the callback once if the policy dictates that we can, re-throwing any
exception encountered so that clients can re-present the same task later.

Execute the callback once if the policy dictates that we can, re-throwing any
exception encountered so that clients can re-present the same task later.

Actions to take after final attempt has failed.

Delegate to the RetryPolicy having checked in the cache for an existing
value if the state is not null.

Register an additional listener.

Setter for listeners.

Extension point for subclasses to decide on behaviour after catching an exception
in a RetryCallback.