防止将 CachingConnectionFactory 与 DefaultJmsListenerContainerFactory 一起使用答案

【问题标题】：Prevent use of CachingConnectionFactory with DefaultJmsListenerContainerFactory防止将 CachingConnectionFactory 与 DefaultJmsListenerContainerFactory 一起使用
【发布时间】：2015-01-17 06:52:11
【问题描述】：

我正在做一个全新的项目，在该项目中我需要有监听器来消费来自多个队列的消息（现在不需要生产者）。

从头开始，我使用的是最新的 Spring JMS 版本（4.1.2）。

这是我的配置文件的摘录：

<bean id="cachedConnectionFactory" 
          class="org.springframework.jms.connection.CachingConnectionFactory"
        p:targetConnectionFactory-ref="jmsConnectionFactory"
        p:sessionCacheSize="3" />

<bean id="jmsListenerContainerFactory"
          class="org.springframework.jms.config.DefaultJmsListenerContainerFactory"
          p:connectionFactory-ref="cachedConnectionFactory"
          p:destinationResolver-ref="jndiDestinationResolver"
          p:concurrency="3-5"
          p:receiveTimeout="5000" />

但我认为我可能错了，因为 DefaultJmsListenerContainerFactory 将构建常规的 DefaultMessageListenerContainerS。而且，正如doc 中所述，CachingConnectionFactory 不应与消息侦听器容器一起使用...

即使我使用新的 Spring 4.1 DefaultJmsListenerContainerFactory 类，post 的答案仍然有效（cacheConsumers = true 可能是一个问题 + 不需要缓存侦听器容器的会话，因为会话是长期存在的），正确的？
我应该使用 SingleConnectionFactory（而不是直接代理实现之一）而不是使用 CachingConnectionFactory？
如果确实应该使用 SingleConnectionFactory 类，是否应该将“reconnectOnException”属性设置为 true（就像在 CachingConnectionFactory 中所做的那样）或者新的“setBackOff”方法（来自 DefaultJmsListenerContainerFactory）是否处理相同类型的问题？

感谢任何提示

【问题讨论】：

标签： spring spring-jms

【解决方案1】：

正确。
除非您想跨多个容器共享单个连接，否则使用SingleConnectionFactory 并没有太多好处；默认情况下，DMLC 将为所有消费者线程 (cacheLevel >= CACHE_CONNECTION) 使用来自供应商工厂的单个连接，除非配置了 TransactionManager。
容器将处理重新连接 - 甚至在“新”backOff 属性之前 - backOff 只是为重新连接算法增加了更多复杂性 - 它过去只是每 n 秒重试一次（默认为 5）。

正如您引用的答案中所述，只要您禁用消费者缓存，就可以使用CCF。

更正：是的，当使用SingleConnectionFactory时，您确实需要将reconnectOnException设置为true，以便容器正确恢复其连接.否则，它只会分发过时的连接。

【讨论】：