我们有一个非常简单的应用程序，其中我们有一个spring integration入站jdbc轮询器，它从数据库表轮询数据，并将这些记录放入直接通道。从该通道，我们有服务激活器，它获取这些记录并将其放入rabbitmq队列。轮询器配置为使用用户定义的ThreadPoolTaskExecutor轮询，最小和最大线程为1，这就是我们想要的。
这个应用程序在轮询固定延迟5秒的几天内运行良好。另外，监视这个线程看起来像是在200毫秒内完成了它的工作。
然后突然间，这个轮询线程停止轮询几分钟，这个间隔有时是1分钟，有时是20分钟。这是不一致的。如果我们重新启动应用程序，那么一旦重新启动它轮询一次又一次，它会回到不一致的轮询。
我们通过 Spring Boot 执行器进行了多个线程转储，如果我们分析这些转储，则我们没有看到任何deaklock。所有线程转储上显示的所有轮询线程都是WAITING状态。
我们使用集成了spring的spring Boot 2.2.6，应用程序部署在PCF中。
自从Spring Boot 从2.1.4升级到2.2.6以来，我们已经看到了这样的行为，但我不能自信地说这一点。
有人能提供一些线索，可能是什么原因导致这种奇怪的行为？
1条答案
按热度按时间f1tvaqid1#
根本原因是这样的：当你在应用中添加@EnableScheduling注解时，Sping Boot 会添加单个线程池。我们也有spring-cloud-config-client作为依赖项，因为我们使用Vault来存储我们的秘密，所以我们必须更新令牌。因此，我们将该令牌作为属性提供。这将添加另一个自动配置的bean以续订保管库令牌。现在，由于池中只有一个线程，并且我们有network/保险库性能问题，该线程一直被卡住，以续订保险库令牌，它很难得到释放，以做数据库轮询。我们还使用默认续订率保险库，这是添加到这个问题。所以有两件事帮助解决这个问题。我们增加了ttl为保险库令牌为24小时，我们的系统管理员修复了网络/保险库性能问题。