Looking at the latest state of affairs in Spring AMQP, things are a bit out of sync:

  • The server-side (interceptors for @RetryTopicListener)requires a RetryPolicy to be set, not a RetryTemplate. The reasoning behind that is that it doesn't use RetryTemplate at all, only what the retry policy provides to compute back off values.
  • The client-side ( RabbitTemplate) still offers a callback to set the retry template. This allows to not only set the retry policy but also any RetryListener that might be required. Custom listeners support was the root cause for RabbitTemplateCustomizer to be added (https://github.com/spring-projects/spring-boot/pull/34050)

RabbitRetryTemplateCustomizer looks wrong now as it is no longer required by the server-side. And this callback only allowed to replace BackOffPolicy & RetryPolicy (configured by properties by default) by new instance that doesn't know about existing settings.

This is required to update to the latest milestone, see #46999.

Comment From: snicoll

For the client-side, we could in theory keep RabbitRetryTemplateCustomizer without the Target attribute. This would be invoked to customize retry features on the client.

However, this makes little sense as the new infrastructure provides two setters only: one to set the RetryPolicy (fully formed) and one to set the RetryListener instance to use (with org.springframework.core.retry.support.CompositeRetryListener being available in case of multiple listeners).

If we want multiple customizers to get a chance to apply, then we need some data structure that allows to register new listeners, tune the retry policy so that it can create the RetryTemplate. A RabbitRetryTemplateSettings could have getter/setter for individual items of the retry policy as well as a ways to register listener. This settings object could then be consume to create the RetryTemplate.

This would change our existing customizer into a RabbitRetryTemplateSettingsCustomizer (a bit mouthful!).

Comment From: snicoll

Fore the server-side, we only need to configure the RetryPolicy. There's no use of the template and no support for listeners so being able to make that distinction is important. Similarly we could have a RabbitRetryPolicySettings that can be used to customizer the policy based on auto-configured settings (typically values from config props).