我最近阅读了很多关于 JMS、Spring(和 TIBCO EMS)关于连接、会话、消费者和生产者的最佳实践
在 Spring 世界中工作时,流行的智慧似乎是
- 用于消费/传入流-
AbstractMessageListenerContainer
与多个消费者/线程一起使用。 - 用于生产/发布流- 在 a
CachingConnectionFactory
下面使用 aJmsTemplate
来维护与代理的单个连接,然后缓存会话和生产者。
对于生产/发布,这就是我的(较大的)服务器应用程序现在正在做的事情,以前它正在为它发布的每条消息(坏!)创建一个新的连接/会话/生产者,因为使用了原始连接工厂下JmsTemplate
. 旧的行为有时会导致在高峰期的短时间内在代理上创建和关闭 1,000 个连接,甚至因此达到套接字/文件句柄限制。
但是,当切换到此模型时,我无法理解使用单个 TCP 连接到代理的性能限制/注意事项是什么。我了解 JMS 提供程序应确保它可以以多线程方式等方式使用 - 但从实际角度来看
- 它只是一个 TCP 连接
- JMS 提供者在某种程度上需要协调写下管道,这样它们就不会最终出现交错的混乱,即使它在其内部协议中有一些分块
- 这肯定涉及使用单个连接的线程/会话之间的一些争用
- 具有一定的网络语义(代理的高延迟?不稳定的吞吐量?)单个连接肯定不是理想的吗?
假设我在正确的轨道上
- 我是否在这里偏离了基础并误解了底层连接如何工作以及由 JMS 提供程序共享?
- 任何争用是通过拥有更多连接来缓解的问题,还是只是将争用转移到代理?
- 有没有人有任何达到他们可以分享的极限的实际经验?具有特定的消息或网络吞吐量,甚至是由并行共享连接的线程/会话数引起的
- 在单连接场景中是否应该担心写入非常大消息的会话会阻塞其他写入小消息的会话?
将不胜感激任何想法或指针,以了解更多关于该主题的阅读或与其他经纪人的经验。