Spring JMS中BackOff与事务仅监听器生效，消息处理失效问题

问题场景 #

我有一个接收IBM MQ消息的IbmMqEndpoint，期望消息处理出错时保留在原队列。当前实现能正常处理无错误消息，但错误消息处理时出现异常：

当前配置代码 #

监听器容器工厂配置

@Bean(name = "ibmMqListenerContainerFactory")
public DefaultJmsListenerContainerFactory ibmMqListenerContainerFactory(
                                          @Qualifier("ibmMqConnectionFactory") ConnectionFactory connectionFactory) {
 DefaultJmsListenerContainerFactory factory = new DefaultJmsListenerContainerFactory();
 factory.setConnectionFactory(connectionFactory);
 factory.setSessionTransacted(true);
 factory.setBackOff(new FixedBackOff(5000L, 3));
 factory.setErrorHandler(new ErrorHandler() {
     @Override
     public void handleError(Throwable t) {
         logger.warn("spring jms custom error handling example");
         logger.error(t.getCause().getMessage());
         throw new MessageSendException("Error", new Exception("Test"));
     }
 });
 return factory;
}

消息监听器注册代码

private SimpleJmsListenerEndpoint getJmsListenerEndpoint(String endpoint) {
 SimpleJmsListenerEndpoint jmsListenerEndpoint = new SimpleJmsListenerEndpoint();
 jmsListenerEndpoint.setId(endpoint);
 jmsListenerEndpoint.setDestination(endpoint);

 jmsListenerEndpoint.setMessageListener(m -> {
     try {
         byte[] body = m.getBody(byte[].class);
         MyMessage myMessage = new MyMessage(body);
         messageHandler.accept(myMessage);
     } catch (MessageSendException | JMSException e) {
         throw new MessageSendException(e);
     }
 });
 return jmsListenerEndpoint;
}

问题现象 #

发送错误消息时会抛出MessageSendException，底层DefaultMessageListenerContainer的waitBeforeRecoveryAttempt方法每次都会调用backOff.start()重置退避尝试次数：

private void waitBeforeRecoveryAttempt() {
     BackOffExecution execution = DefaultMessageListenerContainer.this.backOff.start();
     DefaultMessageListenerContainer.this.applyBackOffTime(execution);
 }

同时handleListenerSetupFailure方法被误触发，但实际并非监听器配置失败，而是消息处理失败。

疑问 #

1. 如何基于Spring Boot实现三次退避尝试？
2. 为什么DefaultMessageListenerContainer的BackOff默认是无限循环？

解决方案及解释 #

一、实现三次退避重试的正确方式 #

当前问题核心是：ErrorHandler中抛出异常会触发容器整体恢复流程（而非单条消息重试），导致退避计数器被重置。要实现单条消息的三次重试，需调整逻辑：

1. 修改ErrorHandler逻辑
   不要在ErrorHandler中抛出异常，仅保留日志记录即可。否则容器会判定为监听器整体故障，进入容器级恢复循环，重置退避次数。

2. 用Spring Retry实现单条消息精准重试
   引入Spring Retry依赖，在消息监听器内包裹处理逻辑，实现指定次数的退避重试：

   jmsListenerEndpoint.setMessageListener(m -> {
       RetryTemplate retryTemplate = new RetryTemplate();
       // 设置退避间隔
       FixedBackOffPolicy backOffPolicy = new FixedBackOffPolicy();
       backOffPolicy.setBackOffPeriod(5000L);
       retryTemplate.setBackOffPolicy(backOffPolicy);
       // 设置最大重试次数
       SimpleRetryPolicy retryPolicy = new SimpleRetryPolicy();
       retryPolicy.setMaxAttempts(3);
       retryTemplate.setRetryPolicy(retryPolicy);
   
       try {
           retryTemplate.execute(context -> {
               byte[] body = m.getBody(byte[].class);
               MyMessage myMessage = new MyMessage(body);
               messageHandler.accept(myMessage);
               return null;
           });
       } catch (RetryException e) {
           // 三次重试失败后，抛出异常触发事务回滚，消息保留在原队列
           logger.error("三次重试均失败，消息保留在队列", e);
           throw new RuntimeException("消息处理失败", e);
       } catch (JMSException e) {
           throw new RuntimeException("JMS操作失败", e);
       }
   });
   

3. 容器配置关键注意点

   • 保持factory.setSessionTransacted(true)：事务未提交时，消息不会被MQ确认，会保留在原队列。
   • 容器的BackOff配置用于容器自身故障恢复（如MQ连接断开后的重连），而非单条消息重试，不要混淆二者用途。

二、DefaultMessageListenerContainer默认无限循环的原因 #

DefaultMessageListenerContainer默认使用NoBackOff（无限重试），原因在于它的设计定位是高可用消息消费容器：

• 容器核心职责是持续监听队列，遇到临时故障（如网络波动、MQ连接中断）时，需要不断尝试恢复，保证消费连续性。
• 这种默认行为是为了避免临时故障导致消费中断，符合大多数消息消费场景的高可用需求。如果需要限制容器级恢复次数，可显式设置FixedBackOff并指定最大重试次数。

内容的提问来源于stack exchange，提问作者Ivan