哪个更好:PooledConnectionFactory或CachingConnectionFactory? [英] Which is better: PooledConnectionFactory or CachingConnectionFactory?

问题描述

我们在Tomcat(7.0.41)中使用Spring(3.2.4)和ActiveMQ(5.8.0)，目前尚不清楚最佳用法.我们要使用JmsTemplate生成消息，并使用MessageListenerContainer接收消息.

我们应该在接收方使用缓存吗? (相关链接)
可以将CachingConnectionFactory与ActiveMQ和故障转移结合使用吗? (相关链接)
使用PooledConnectionFactory时需要设置useAsyncSend ="true"吗? (相关链接)

We use Spring (3.2.4) with ActiveMQ (5.8.0) in Tomcat (7.0.41) and it is not clear what the best usage. We want to use JmsTemplate to produce and MessageListenerContainer to receive messages.

Should we use caching in receiver side? (related link)
Works CachingConnectionFactory with ActiveMQ and failover? (related link)
Need to set useAsyncSend="true" when we use PooledConnectionFactory? (related link)

推荐答案

来自此处:

PooledConnectionFactory和CachingConnectionFactory之间的差异是实现上的差异.以下是它们之间不同的一些特征:

The difference between the PooledConnectionFactory and the CachingConnectionFactory is a difference in implementation. Below are some of the characteristics that differ between them:

• 尽管PooledConnectionFactory和CachingConnectionFactory都声明它们各自池化连接，会话和生产者，但PooledConnectionFactory实际上并未创建多个生产者的缓存.当请求一个生产者时，它仅使用单例模式来分发单个缓存的生产者.而CachingConnectionFactory实际上创建了一个包含多个生产者的缓存，并在请求一个生产者时从该缓存中分发了一个生产者.

• Although both the PooledConnectionFactory and the CachingConnectionFactory state that they each pool connections, sessions and producers, the PooledConnectionFactory does not actually create a cache of multiple producers. It simply uses a singleton pattern to hand out a single cached producer when one is requested. Whereas the CachingConnectionFactory actually creates a cache containing multiple producers and hands out one producer from the cache when one is requested.

PooledConnectionFactory建立在Apache Commons Pool项目的顶部，用于池化JMS会话.这允许对池进行一些其他控制，因为Commons Pool中的某些功能没有被PooledConnectionFactory使用.这些附加功能包括增大池的大小而不是阻塞池，在池用尽时引发异常等.您可以使用以下功能来利用这些功能:使用自己的自定义设置创建自己的Commons Pool GenericObjectPool，然后通过setPoolFactory方法.有关其他信息，请参见以下内容: http: //commons.apache.org/pool/api-1.4/org/apache/commons/pool/impl/GenericObjectPoolFactory.html

The PooledConnectionFactory is built on top of the Apache Commons Pool project for pooling JMS sessions. This allows some additional control over the pool because there are features in Commons Pool that are not being used by the PooledConnectionFactory. These additional features include growing the pool size instead of blocking, throwing an exception when the pool is exhausted, etc. You can utilize these features by creating your own Commons Pool GenericObjectPool using your own customized settings and then handing that object to the PooledConnectionFactory via the setPoolFactory method. See the following for additional info: http://commons.apache.org/pool/api-1.4/org/apache/commons/pool/impl/GenericObjectPoolFactory.html

CachingConnectionFactory还可以缓存使用者.使用此功能时只需要注意，这样您就可以根据博客文章中提到的规则来缓存使用者.

The CachingConnectionFactory has the ability to also cache consumers. Just need to take care when using this feature so that you know the consumers are cached according to the rules noted in the blog post.

但最重要的是，CachingConnectionFactory将与任何符合JMS的MOM一起使用.它只需要一个JMS连接工厂.如果您使用多个MOM供应商，这在企业组织中很常见(这主要是由于旧项目和现有项目所致)，则这一点很重要.重要的是，CachingConnectionFactory不仅可以与ActiveMQ一起使用，而且可以与许多不同的MOM实现很好地配合.

来自此处:

• 如果您已群集ActiveMQ，并使用故障转移传输，则报告说CachingConnectionFactory不是正确的选择.

我遇到的问题是，如果一个盒子掉了，我们应该开始 对方发送邮件，但似乎仍在使用旧的 连接(每次发送超时).如果我重新启动程序，它将 重新连接，一切正常.来源: ActiveMQ和CachingConnectionFactory的自动重新连接问题

The problem I’m having is that if one box goes down, we should start sending messages on the other, but it seems to still be using the old connection (every send times out). If I restart the program, it’ll connect again and everything works. Source: Autoreconnect problem with ActiveMQ and CachingConnectionFactory

问题是与失败的ActiveMQ的缓存连接为 仍在使用中，这给用户带来了问题.现在 此方案的选择是PooledConnectionFactory.

The problem is that cached connections to the failed ActiveMQ was still in use and that created the problem for the user. Now, the choice for this scenario is PooledConnectionFactory.

如果您今天使用的是ActiveMQ，并且将来可能会切换到其他某些代理(JBoss MQ，WebSphere MQ)，请不要使用 PooledConnectionFactory，因为它将代码紧密地耦合到了 ActiveMQ.

If you’re using ActiveMQ today, and chances are that you may switch to some other broker (JBoss MQ, WebSphere MQ) in future, do not use PooledConnectionFactory, as it tightly couples your code to ActiveMQ.

这篇关于哪个更好:PooledConnectionFactory或CachingConnectionFactory?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！