MqttPahoMessageHandler和重新连接速率管理

Question

我们注意到一些使用Spring Integration与MQTT的应用程序在短时间间隔内发现了很多重新连接尝试，导致我们正在使用的代理发生问题。我认为部分问题是MqttPahoMessageHandler似乎没有使用任何连接退避算法。对于入站连接，它看起来像MqttPahoMessageDrivenChannelAdapter采用恒定退避（例如recoveryInterval），我认为PAHO的较新版本（> = 1.1）具有用于指数退避支持。使用MqttPahoMessageHandler，似乎每个消息发布都会导致新的连接尝试（如果尚未连接）。

在我们的环境中，我们已经看到以下场景：

1. 我们的经纪人在接受短的时间内有很多所连接的，造成MQTT将消息排队。
2. 意愿排队最终达到最高容量。
3. 的MQTT连接将不会成功：
   1. TCP连接设置
   2. 与意愿MQTT CONNECT消息发送
   3. 经纪人试图排队意愿消息，该消息失败
   4. 经纪人终止TCP连接

发生这种情况时，如果我们试图发送一个LO t的出站消息，我们看到很多来自的连接尝试MqttPahoMessageHandler + Paho。

是否有一个原因，出站连接（MqttPahoMessageHandler）什么是用于入站连接（MqttPahoMessageDrivenChannelAdapter）或泛美卫生组织不要使用再连接一退避算法，类似于？

我想修改此行为，但首先想了解这是否是有意设计决策？

Answer 1

所有Spring集成出站端点将尝试按需连接。

您可以添加一个Circuit Breaker Advice来防止这种情况发生。当检测到可配置的故障次数时，断路器将被打开，并且随后的尝试将快速失败。过了一段时间，破坏者半开放，允许尝试;如果失败了，它会再次打开。