應用的監聽器注解
@JmsListener(destination = "TopicName",containerFactory = "FactoryName")
工廠代碼
@BeanJmsListenerContainerFactory<?> FactoryName(ConnectionFactory connectionFactory){SimpleJmsListenerContainerFactory factory = new SimpleJmsListenerContainerFactory();factory.setConnectionFactory(connectionFactory);factory.setPubSubDomain(true);return factory;}
修改后的工廠代碼
@Beanpublic 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 和會話緩存，能夠更可靠地恢復監聽，因此更適合用于生產環境。
