0

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)?

MainS
  • 120
  • 1
  • 6

2 Answers2

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.

Ady
  • 584
  • 8
  • 16
  • What will be more efficient to use for exampe for Mono? It's obvious that retries will be occurred only after response has received. Therefore, I think there is no difference if operation is blocking or not. – MainS Dec 28 '22 at 09:06
  • If you are going to use webflux (with methods returning Mono/Flux operators), then you must use webflux's retry. Remember, if you are working on event loop then the error will surface in the pipeline not on the method level, so with retry operator you are retrying the event in the pipeline. @Retryable is something which works on blocking calls, it means that it may not behave in the way you'd expect it to work since your exception won't surface on the method level. It may happen that you'd forward your exception further up in the pipeline where there is no retry happening. – Ady Dec 28 '22 at 10:24
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.

Anghel Ionut
  • 61
  • 5
  • What will be more efficient to use for exampe for Mono? It's obvious that retries will be occurred only after response has received. Therefore, I think there is no difference if operation is blocking or not. – MainS Dec 28 '22 at 09:06
  • 1
    It is generally more efficient to use the retry operator in WebFlux for retrying failed requests, especially when working with reactive streams like Mono. This is because the retry operator is designed specifically for this purpose and can be easily applied to a reactive stream. – Anghel Ionut Dec 28 '22 at 09:45