Java 哪个更好:PooledConnectionFactory 或 CachingConnectionFactory?

声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow 原文地址: http://stackoverflow.com/questions/19560479/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me): StackOverFlow

提示:将鼠标放在中文语句上可以显示对应的英文。显示中英文
时间:2020-08-12 18:20:20  来源:igfitidea点击:

Which is better: PooledConnectionFactory or CachingConnectionFactory?

javaspringtomcatjmsactivemq

提问by Krayo

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)

我们在 Tomcat (7.0.41) 中使用 Spring (3.2.4) 和 ActiveMQ (5.8.0),目前尚不清楚什么是最佳用法。我们想使用 JmsTemplate 来产生和 MessageListenerContainer 来接收消息。

我们应该在接收端使用缓存吗?(相关链接
使用 ActiveMQ 和故障转移工作 CachingConnectionFactory?(相关链接)
使用 PooledConnectionFactory 时需要设置 useAsyncSend="true" 吗?(相关链接

采纳答案by Arya

From here:

这里

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 之间的区别在于实现上的不同。以下是它们之间不同的一些特征:

  • 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.

  • 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

  • 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.

  • But most importantly, the CachingConnectionFactory will work with any JMS compliant MOM. It only requires a JMS connection factory. This is important if you are using more than one MOM vendor which is very common in enterprise organizations (this is mainly due to legacy and existing projects). The important point is that the CachingConnectionFactory works very well with many different MOM implementations, not only ActiveMQ.

  • 尽管 PooledConnectionFactory 和 CachingConnectionFactory 都声明它们各自池连接、会话和生产者,但 PooledConnectionFactory 实际上并没有创建多个生产者的缓存。它只是使用单例模式在请求时分发一个缓存的生产者。而 CachingConnectionFactory 实际上创建了一个包含多个生产者的缓存,并在请求一个生产者时从缓存中分发一个生产者。

  • PooledConnectionFactory 建立在 Apache Commons Pool 项目之上,用于池化 JMS 会话。这允许对池进行一些额外的控制,因为公共池中有 PooledConnectionFactory 未使用的功能。这些附加功能包括增加池大小而不是阻塞、在池耗尽时抛出异常等。您可以通过使用您自己的自定义设置创建自己的 Commons Pool GenericObjectPool 然后将该对象通过 PooledConnectionFactory 传递给 PooledConnectionFactory 来利用这些功能setPoolFactory 方法。有关其他信息,请参阅以下内容:http: //commons.apache.org/pool/api-1.4/org/apache/commons/pool/impl/GenericObjectPoolFactory.html

  • CachingConnectionFactory 还可以缓存使用者。使用此功能时只需要小心,以便您知道消费者是根据博客文章中指出的规则进行缓存的。

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

From here:

这里

  • If you have clustered ActiveMQs, and use failover transport it has been reported that CachingConnectionFactory is not a right choice.

  • 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

  • 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.

  • 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.

  • 如果您有集群 ActiveMQ,并使用故障转移传输,据报告 CachingConnectionFactory 不是一个正确的选择。

  • 我遇到的问题是,如果一个盒子坏了,我们应该开始在另一个盒子上发送消息,但它似乎仍在使用旧连接(每次发送超时)。如果我重新启动程序,它会再次连接并且一切正常。来源: ActiveMQ 和 CachingConnectionFactory 的自动重新连接问题

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

  • 如果您现在正在使用 ActiveMQ,并且将来可能会切换到其他代理(JBoss MQ、WebSphere MQ),请不要使用 PooledConnectionFactory,因为它会将您的代码与 ActiveMQ 紧密耦合。