为什么DefaultMessageListenerContainer不应该使用CachingConnectionFactory? [英] Why DefaultMessageListenerContainer should not use CachingConnectionFactory?

查看:164
本文介绍了为什么DefaultMessageListenerContainer不应该使用CachingConnectionFactory?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在阅读 DefaultMessageListenerContainer

它说:注意:不要将Spring的CachingConnectionFactory与动态缩放结合使用.理想情况下,根本不要将它与消息侦听器容器一起使用,因为通常最好让侦听器容器本身在其中处理适当的缓存.而且,停止和重新启动侦听器容器仅适用于独立的本地缓存的Connection,而不适用于外部缓存的Connection."

It says "Note: Don't use Spring's CachingConnectionFactory in combination with dynamic scaling. Ideally, don't use it with a message listener container at all, since it is generally preferable to let the listener container itself handle appropriate caching within its lifecycle. Also, stopping and restarting a listener container will only work with an independent, locally cached Connection - not with an externally cached one."

有人可以解释为什么吗?

Could anybody explain why?

推荐答案

  1. 您真的不需要为侦听器容器缓存会话,因为这些会话是长期存在的.缓存对于频繁短时间使用(例如JmsTemplate)非常有益.
  2. 问题实际上是当cacheConsumers = true(默认值)时出现的.使用动态缩放并停止侦听器时,会话将返回到高速缓存,但是代理不知道实际上没有人会从该会话中使用,因此,您将被困在高速缓存中的消息所困扰,直到被读取为止音量增加时,该会话恰好可以重用.
  1. You really don't need to cache sessions for listener containers because the sessions are long lived; caching is very beneficial for frequent short use, such as with the JmsTemplate.
  2. The problem is really when cacheConsumers = true (the default). When using dynamic scaling and a listener is stopped, the session is returned to the cache but the broker doesn't know that nobody will actually consume from that session, so you are stuck with messages sitting in the cache that won't be read until that session happens to be reused when the volume increases.

注意:如果希望在容器线程上运行的JmsTemplate参与容器事务,则使用CachingConnectionFactory,以便可以缓存生产者,但是应该禁用缓存如果您具有可变的并发性,那么工厂中的使用者.

Note: if you wish a JmsTemplate running on the container thread to participate in a container transaction, you should use a CachingConnectionFactory so the producers can be cached, but you should disable caching consumers in the factory if you have variable concurrency.

这篇关于为什么DefaultMessageListenerContainer不应该使用CachingConnectionFactory?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆