Spring集成线程限制

Question

我们有一个SI应用程序，用于路由消息，进行一些验证，转换和过滤。

本质上，它使用来自各种队列的JMS消息，并将它们路由到预先注册的下游出站JMS队列。

我们通过春季配置管理所有这些。

在1个JVM内部，我们有几百个（400-500个）队列通道和相关的轮询器。

我们注意到我们扩大规模（添加新的入站和出站路线），我们的性能有所下降。

我们似乎对盒子（CPU，内存等）的影响似乎都没有得到充分利用。

当分析应用程序时，

• ~650线程总计Runnable
• 0-2被阻止0（有时达到10左右的尖峰，似乎无法找到阻挡它们的东西）
• 在Net I / O~100 +（通常等待JMS接收）
• 等待~500

我们从卷的角度对应用程序进行了负载测试，但是正在从入站和出站处理流程的扩展中查看它。

我们在盒子上运行了其中的几个（都指向不同的外部JMS资源），但我们只看到其中一个JVM（配置了最多入站和出站流量的JVM）的速度减慢。

从长远来看，我们正在努力理解

1. 对于轮询器+队列通道，SI是否有缩放限制？
2. 可能有些限制，有什么症状，怎么检测？
3. 这里的约束是什么，线程上下文切换？别的什么？
4. 我们是旧版本的SI（1）是否已经对这种类型的架构进行了改进，还是需要进行重新设计？
5. 高并发的替代架构，多个入站和出站通道之间的事件样式路由？每个入站和出站通道仍然有一组可能贯穿的内容（转换，过滤，验证）

Answer 1

为什么这么多队列频道？在流中有多个异步切换（如果有的话）是不寻常的，通常是不必要的。通常根本不需要，尤其是在使用消息驱动的入站端点（例如JMS消息驱动的适配器）时。

这是因为线程和并发可以完全由适配器的消息侦听器容器管理。

最有效的配置是将入站适配器上的并发（线程数）设置为所需的并且始终使用直接通道。

事实上，如果您不希望丢失消息，则需要这样做;只要在队列通道中传递消息，JMS消息就会被激活（默认情况下）。