Spring @Retryable vs WebFlux retry

Question

Could somebody help with understanding the difference between using @Retryable on metod which contains WebFlux client call and retries that are supported by WebFlux itself (e.g. retryWhen)?

Answer 1

@Retryable is a Spring annotation that can be used to automatically retry a method if it fails due to an exception. When a method is annotated with @Retryable, Spring will intercept the method call and automatically retry it if the method throws an exception that is listed in the include attribute of the annotation. @Retryable works with traditional blocking methods and is suitable for use in a synchronous, request-response style of programming.

WebFlux is a non-blocking, reactive programming model for building reactive applications in Spring. It provides support for reactive streams and allows you to build applications that can scale to handle high levels of concurrency with a small number of threads. WebFlux also provides a retry operator for its Mono and Flux types, which allows you to retry an asynchronous operation if it fails. This operator is similar to the @Retryable annotation but is designed to work with reactive streams rather than traditional blocking methods.

Here are some key differences between @Retryable and the WebFlux retry operator:

@Retryable works with traditional blocking methods, while the retry operator works with reactive streams. @Retryable is used to annotate a method, while the retry operator is called on a Mono or Flux object. @Retryable retries a method if it throws an exception, while the retry operator retries an operation if it fails (e.g., if it produces an error signal). @Retryable allows you to specify the maximum number of retries and the backoff policy for retries, while the retry operator allows you to specify the maximum number of retries and a retry predicate to determine when to retry.

Answer 2

The main difference which comes to my mind is, in order to use @Retryable your method needs to called from outside of the class, because under the hood @Retryable makes use of spring's Aspect Oriented Programming which makes use of proxy to call retires on your target method. This primary meant to be used for blocking methods. The spring webflux retry on other hand is meant for a non-blocking calls when your functional pipeline emits the exception to it's subscriber and you'd want to re-attempt within the pipeline itself, this should work on private methods too.