Mastering Spring Retry: Using @Retryable and @Recover for Robust Java Applications

Preface

In real‑world development, retrying failed operations is a frequent requirement, such as when sending a message fails, a remote service call fails, or a lock acquisition fails. These errors are often caused by temporary network glitches, and a simple retry after a short wait can succeed.

Typical code uses try/catch or a while loop, but this approach lacks consistency and adds boilerplate. The spring-retry module provides annotation‑based retry handling without intruding on business logic.

What is @Retryable?

The Spring spring-retry module offers a utility for standardised retry handling. All configuration is driven by simple annotations.

Usage Steps

POM Dependency

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

Enable @Retryable

@EnableRetry
@SpringBootApplication
public class HelloApplication {
    public static void main(String[] args) {
        SpringApplication.run(HelloApplication.class, args);
    }
}

Add @Retryable to a Method

import com.mail.elegant.service.TestRetryService;
import org.springframework.retry.annotation.Backoff;
import org.springframework.retry.annotation.Retryable;
import org.springframework.stereotype.Service;
import java.time.LocalTime;

@Service
public class TestRetryServiceImpl implements TestRetryService {
    @Override
    @Retryable(value = Exception.class, maxAttempts = 3,
               backoff = @Backoff(delay = 2000, multiplier = 1.5))
    public int test(int code) throws Exception {
        System.out.println("test called, time: " + LocalTime.now());
        if (code == 0) {
            throw new Exception("Invalid condition!");
        }
        System.out.println("test succeeded!");
        return 200;
    }
}

The annotation parameters have the following meanings: value: the exception types that trigger a retry. include: same as value; if both include and exclude are empty, all exceptions are retried. exclude: exception types that should not be retried. maxAttempts: maximum number of retry attempts (default 3). backoff: retry back‑off strategy; @Backoff defines the delay and multiplier. The default delay is 1000 ms; in the example it is set to 2000 ms with a multiplier of 1.5, resulting in delays of 2 s, 3 s, and 4.5 s for successive attempts.

When all retries are exhausted, Spring Retry can delegate control to a RecoveryCallback or use the @Recover annotation to define a fallback method.

@Recover

@Recover
public int recover(Exception e, int code) {
    System.out.println("Recovery method executed!");
    // log to database or perform alternative actions
    return 400;
}

The recovery method must have a first parameter of type Throwable (usually the same exception type specified in @Retryable) and a return type that matches the original method. It should reside in the same class as the retryable method.

Important Notes

Because Spring Retry is based on AOP, self‑invocation within the same class will not trigger retries.

If a retry fails and you need custom handling, the retryable method must return void and the logic should be placed in the @Recover method.

Do not use try/catch inside the retryable method; let exceptions propagate.

The @Recover method’s parameters must align with the exception type declared in @Retryable.

Summary

This article introduced the use of Spring Boot’s @Retryable annotation, its typical scenarios, configuration steps, and key considerations. When you need to automatically retry failed operations, Spring Retry provides a clean, annotation‑driven solution.