Support `RetryListener` registration via `@Retryable`

[alexey-kadyrov]

It appears that the support for @Retryable is not complete.

The RetryListener API is defined but is not actually used in conjunction with @Retryable.

A new instance of RetryTemplate is created each time in AbstractRetryInterceptor when a retryable operation is called but without setting a RetryListener.

		RetryPolicy retryPolicy = RetryPolicy.builder()
				// ...
				.build();
		RetryTemplate retryTemplate = new RetryTemplate(retryPolicy);

		try {
			return retryTemplate.execute(new Retryable<>() {

[sbrannen]

Hi @alexey-kadyrov,

Thanks for raising this issue.

The @Retryable annotation from the Spring Retry project does indeed have a listeners attribute, but the @Retryable annotation in Spring Framework does not currently have such support.

Note, however, that RetryListener is supported for programmatic usage with the RetryTemplate.

Thus, we will discuss this within the team to decide if we wish to introduce similar functionality in @Retryable.

[sbrannen]

As I alluded to above, the RetryListener API is tied directly to implementation details of the RetryTemplate, such as RetryPolicy, Retryable, and RetryException.

As such, the RetryListener API does not map directly to all @Retryable use cases, some of which may be reactive (based on the Reactor Retry support).

Thus, there is no straightforward option for supporting the RetryListener API with @Retryable in Spring Framework.

We would like to know what your "listener" requirements are when using @Retryable.

In light of that, can you please share your concrete use case with us?

Thanks

[alexey-kadyrov]

In light of that, can you please share your concrete use case with us?

The use case is to add support for micrometer metrics for the retries caused by using @Retryable.

In overall I prefer this implementation over the one in spring-retry mostly due that it's more developer friendly (@Retryable has all properties as opposite having @Backoff) considering the limitations of Java's annotations, e.g. absence of inheritance and doesn't require an additional dependency.

[jhoeller]

@bclozel I suppose we could build Micrometer support right into AbstractRetryInterceptor itself, similar to how we have out-of-the-box Micrometer support elsewhere already? Knowing what we need to expose for Micrometer purposes, we could adapt this separately: to RetryTemplate/RetryListener as well as to Reactor's RetryBackoffSpec and its before/after/exhaustion callbacks, covering both code paths in AbstractRetryInterceptor.

[bclozel]

I understand that Spring Retry had Micrometer support, but I am not sure about the main goal here.

Observations should be about a specific, well-defined event: processing an HTTP request, a scheduled method, a JMS message.

Here, a retryable event can happen for all of those things. This is actually quite similar to Cacheable, as it is a cross cutting concern. Looking at "spring.retryable" events will not be very useful as they will be about HTTP, JMS, database calls and more. If retryable wraps a RestClient call, you would already get 3 observations (possibly in a single trace).

Which leads to another question: how are those supposed to be modeled within a trace? I am not seeing anything related to retries in the OTel semantic conventions.

[jhoeller]

Good point, @bclozel. From that perspective, it's not an obvious candidate for out-of-the-box observability instrumentation.

@alexey-kadyrov do you have an existing arrangement for observability that you intend to migrate here?