Solace - Spring 集成缓慢答案

【问题标题】：Solace - Spring integration slownessSolace - Spring 集成缓慢
【发布时间】：2018-10-17 01:14:41
【问题描述】：

我们使用 solace 作为模块和子系统之间的消息总线。我们的应用程序建立在 Spring Boot 和 Spring 集成（消息驱动通道适配器、DefaultMessageListenerContainer、CachingConnectionFactory）之上。

我们观察到每隔几天就会出现 10-15 分钟的随机缓慢。在某些基于日志的情况下，只有从模块 1 的发送者到模块 2 的接收者需要 15 分钟，并且两者之间也没有服务激活器。

有人遇到过类似的问题吗？关于解决此问题的任何建议？

【问题讨论】：

我建议为org.springframework.integration 类别打开DEBUG 日志记录级别。这样你会看到很多 preSend 和 postSend 以及其他一些 Spring Integration 有用的日志。这应该会给你一些线索，你的系统卡在哪里。还要确保内存和 GC 一切正常。在这件事上使用 Visual VM。
感谢Artem的好建议，我会启用特定jms包的调试日志。对于内存大小，我已经验证它远低于最大限制。我也验证了这段时间内的负载，可以忽略不计。
在我们的代码中，我们使用 CachingConnectionFactory 的动态缩放。这可能是该线程link 中解释的潜在问题
日志也确认了相同的行为。假设 Listener-4 在 12:01 使用，并在 12:17 再次使用，在其未使用之间。似乎 Listener-4 消费了消息，但由于 CachingConnectionFactory 中的缓存，并没有真正将消息传递给通道适配器。

【解决方案1】：

这确实是一个很好的问题，它帮助我了解了 SI 和 JMS 的几个方面。我正在写这个答案，希望有类似问题的人能得到一些信息。我们的方案中存在不止一个问题，以下是重点：

为 DMLC 移除缓存连接工厂在很大程度上解决了这个问题。
我们正在使用从 DMLC 到流完成的阻塞流。在某些情况下，我们的服务激活器在持久化期间卡住了。
我们的消息代理设置了 18 的预取设置，这允许多达 18 条消息在没有确认的情况下传递给消费者。在我们的案例中，一条消息卡在我们的服务激活器中，流程被阻塞，但 jms 消费者不断获取多达 18 条消息，而没有将其传递给 DMLC 代理。我们将预取减少到 1 个，这有助于将卡住的消息数量减少到只有一个。
我们怀疑 mysql 连接是否在某些不活动情况下被丢弃，如该线程 MySQL database drops connection after 8 hours. How to prevent it? 中所述。我们通过添加验证查询添加了数据源保持活动设置。这有助于我们将卡住的消息减少到零。

【讨论】：