ActiveMQ监听器在MQ重启后不再监听问题

应用的监听器注解

@JmsListener(destination = "TopicName",containerFactory = "FactoryName")

工厂代码

@Bean
    JmsListenerContainerFactory<?> FactoryName(ConnectionFactory connectionFactory){
        SimpleJmsListenerContainerFactory factory = new SimpleJmsListenerContainerFactory();
    	factory.setConnectionFactory(connectionFactory);
        factory.setPubSubDomain(true);
        return factory;
    }

修改后的工厂代码

@Bean
    public JmsListenerContainerFactory<?> FactoryName(ConnectionFactory connectionFactory) {
        DefaultJmsListenerContainerFactory factory = new DefaultJmsListenerContainerFactory();
        factory.setConnectionFactory(connectionFactory);
        factory.setPubSubDomain(true); // 启用Topic模式
        factory.setRecoveryInterval(5000L); // 每5秒尝试恢复连接（关键配置！）
        return factory;
    }

优劣势

• SimpleJmsListenerContainerFactory 的局限性:
  它缺乏可靠的重连机制，无法保证在 MQ 重启后能够恢复监听。
  没有配置重连间隔（如 recoveryInterval），导致重连行为不可控。

• DefaultJmsListenerContainerFactory 的优势:
  提供了可靠的重连机制，支持自定义重连间隔（如 setRecoveryInterval(5000L)）。
  支持会话缓存，能够更高效地恢复监听。
  在 MQ 重启后，能够自动恢复连接并继续监听消息。

注意:如果必须使用 SimpleJmsListenerContainerFactory，可以在应用层实现自定义的重连逻辑，但这种方式复杂且不够可靠。

总结

第一个代码（使用 SimpleJmsListenerContainerFactory）在 MQ 重启后可能无法实现重新监听，因为它缺乏可靠的重连机制和重连间隔配置。第二个代码（使用 DefaultJmsListenerContainerFactory）通过配置 recoveryInterval 和会话缓存，能够更可靠地恢复监听，因此更适合用于生产环境。