防止将 CachingConnectionFactory 与 DefaultJmsListenerContainerFactory 一起使用 [英] Prevent use of CachingConnectionFactory with DefaultJmsListenerContainerFactory

问题描述

我正在开发一个全新的项目，在该项目中，我需要使用来自多个队列的消息的侦听器(暂时不需要生产者).

I am working on a brand new project in which I need to have listeners that will consume messages from several queues (no need to have producer for now).

从头开始，我使用的是最新的 Spring JMS 版本 (4.1.2).

Starting from scratch, I am using the last Spring JMS version (4.1.2).

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

Here is an extract of my configuration file:

<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 不应与消息侦听器容器一起使用...

But I think I may be wrong since DefaultJmsListenerContainerFactory will build regular DefaultMessageListenerContainerS. And, as stated in the doc, CachingConnectionFactory should not be used with a message listener container...

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

• Even if I am using the new Spring 4.1 DefaultJmsListenerContainerFactory class the answer from post is still valid (cacheConsumers = true can be an issue + don't need to cache sessions for listener containers because the sessions are long lived) , right?
• Instead of using the CachingConnectionFactory, I should use the SingleConnectionFactory (and not directly the broker implementation one)?
• If the SingleConnectionFactory class should indeed be used, is the "reconnectOnException" property should be set to true (as it is done in the CachingConnectionFactory) or does the new "setBackOff" method (from DefaultJmsListenerContainerFactory) deals with the same kind of issues?

感谢您的建议

推荐答案

• 正确.
• 使用 SingleConnectionFactory 并没有太大的好处，除非您想在多个容器之间共享一个连接；DMLC 将默认使用来自供应商工厂的单个连接用于所有消费者线程(cacheLevel >= CACHE_CONNECTION)，除非 TransactionManager 是配置.
• 容器将处理重新连接 - 甚至在新"backOff 属性之前 - backOff 只是为重新连接算法增加了更多的复杂性 - 它曾经只是重试每 n 秒(默认为 5 秒).
• Correct.
• There's not really much benefit in using a SingleConnectionFactory unless you want to share a single connection across multiple containers; the DMLC will use a single connection from the vendor factory by default for all consumer threads (cacheLevel >= CACHE_CONNECTION), unless a TransactionManager is configured.
• The container(s) will handle reconnection - even before the 'new' backOff property - backOff just adds more sophistication to the reconnection algorithm - it used to just retry every n seconds (5 by default).

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

As stated in the answer you cited, it's ok to use a CCF as long as you disable consumer caching.

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

Correction: Yes, when using the SingleConnectionFactory, you do need to set reconnectOnException to true in order for the container to properly recover its connection. Otherwise, it simply hands out the stale connection.

这篇关于防止将 CachingConnectionFactory 与 DefaultJmsListenerContainerFactory 一起使用的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！