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
和会话缓存,能够更可靠地恢复监听,因此更适合用于生产环境。