Spring Retry

A BackoffPolicy defines how long the RetryTemplate should wait between retry attempts. This is useful for transient failures where waiting allows the underlying issue to resolve.

Common implementations include:

• ExponentialBackoffPolicy: Increases the wait period exponentially between attempts to avoid synchronized retries (lock-step).
• Randomized/Jitter policies: Adds randomness to the delay to prevent resonance between related failures in complex systems.

All Spring Retry policies use Object.wait() for the delay implementation.

public interface BackoffPolicy {

    BackOffContext start(RetryContext context);

    void backOff(BackOffContext backOffContext)
        throws BackOffInterruptedException;

}

Spring Retry uses two primary callback interfaces to manage the retry lifecycle:

1. RetryCallback<T, E>: Contains the business logic to be retried via the doWithRetry(RetryContext context) method.
2. RecoveryCallback<T>: Contains the fallback logic to be executed if the RetryCallback fails after all retry attempts are exhausted.

You can pass both to a RetryOperations.execute() method to handle both the main logic and the recovery logic.

MyObject myObject = template.execute(new RetryCallback<MyObject, Exception>() {
    public MyObject doWithRetry(RetryContext context) {
        // business logic here
    },
  new RecoveryCallback<MyObject>() {
    MyObject recover(RetryContext context) throws Exception {
          // recover logic here
    }
});

Spring Retry supports two modes of operation:

• Stateless Retry: The simplest form where the retry is essentially a loop. The RetryContext state exists only on the stack, and the callback is always executed in the same thread that failed. This is suitable for transient errors like network glitches.
• Stateful Retry: Used when a failure requires a transactional rollback (e.g., database updates with Hibernate). Because a rollback requires leaving the current execution context, the state must be lifted off the stack into heap storage. This is managed using a RetryContextCache and a RetryState object that provides a unique key to identify the item across multiple invocations.

You can apply retry logic declaratively using annotations. This requires @EnableRetry on a configuration class and an additional runtime dependency on AOP classes.

1. Annotate a method with @Retryable to specify which exceptions should trigger a retry and how many attempts to make.
2. Annotate a method with @Recover to define the fallback logic that executes when all retry attempts are exhausted.

@Configuration
@EnableRetry
public class Application {

}

@Service
class Service {
    @Retryable(retryFor = RemoteAccessException.class)
    public void service() {
        // ... do something
    }
    @Recover
    public void recover(RemoteAccessException e) {
       // ... panic
    }
}

To use Spring Retry in your project, add the following dependency to your pom.xml. Note that this project is currently archived and has been superseded by Spring Framework 7's resilience features.

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

Using @Retryable requires AOP (Aspect-Oriented Programming) dependencies at runtime.

For Spring Boot applications: Add the Spring Boot starter for AOP via Gradle:

runtimeOnly 'org.springframework.boot:spring-boot-starter-aop'

For non-Boot applications: Add a runtime dependency on the latest version of AspectJ's aspectjweaver module via Gradle:

runtimeOnly 'org.aspectj:aspectjweaver:1.9.20.1'

Starting with version 2.0.8, you can monitor retry operations using the MetricsRetryListener. This listener uses a Micrometer MeterRegistry to expose a spring.retry timer.

The timer tracks the duration from the open() to the close() listener callbacks, covering the entire retry operation. It automatically includes the following tags:

• name: Based on the value returned by RetryCallback.getLabel().
• retry.count: The number of retries performed (0 if the first call succeeds).
• exception: The last exception thrown if all retry attempts are exhausted.

You can integrate this listener by:

1. Injecting it into a RetryTemplate.
2. Referencing it via the @Retryable(listeners = ...) attribute.

MetricsRetryListener can be customized with static tags or via a Function<RetryContext, Iterable<Tag>> to add dynamic tags.

You can configure declarative retry using Spring AOP XML configuration. This involves defining a pointcut for the target methods and an advisor using RetryOperationsInterceptor.

<aop:config>
    <aop:pointcut id="transactional"
        expression="execution(* com..*Service.remoteCall(..))" />
    <aop:advisor pointcut-ref="transactional"
        advice-ref="retryAdvice" order="-1"/>
</aop:config>

<bean id="retryAdvice"
    class="org.springframework.retry.interceptor.RetryOperationsInterceptor"/>

To customize the retry policies or listeners in XML, inject a configured RetryTemplate into the RetryOperationsInterceptor bean.