在MQ Light中重新发送行为

Question

我在MQ Light中尝试确保交付。

我正在使用带有修改过的mqlight输入节点的Node-RED。我在subscribe（）调用中添加了以下选项：

qos: mqlight.QOS_AT_LEAST_ONCE, autoConfirm: false, ttl: (60 * 60 * 24 * 1000)

这要求我调用delivery.message.confirmDelivery（）来向MQ Light确认收到消息。

下面的屏幕截图是mqlight_NodeREDClient的订阅设置为autoConfirm为false，收到消息，但没有调用delivery.message.confirmDelivery（）。这是为了模拟Node-RED流中出现的某种错误。

我已经修改了Node-RED流程以执行confirmDelivery（），并且现在流程消耗的任何消息都被确认，即使Node-RED在发布时没有运行。消息由MQ Light保存，因为目标上有一个TTL，一旦我再次启动Node-RED就会到达。

但是，此屏幕截图中已经发送过一次但从未确认过的消息永远不会被重新发送。重新启动Node-RED不会改变这一点，该消息仍处于未决状态。要使MQ Light重新传输之前已发送但从未由客户端确认的消息，需要满足哪些条件？

Answer 1

如果您还没有重新启动NodeRED，我说这是因为MQ Light不会重新连接到已连接的客户端，因为它认为客户端仍在处理该消息。但是，因为你有它必须是别的东西。

我只是尝试了相同的基本设置（没有NodeRED）并且行为正如您所期望的那样 - 当您重新连接接收客户端时，MQ Light会重新传递消息，并且MQ Light UI将其关闭。

我能想到的其余事情是：

1. 当发送特定消息时，您是否有可能获得QoS 0 订阅？
2. 您在发件人的邮件上设置了什么TTL？
3. 您在订阅电话上设置了哪个目的地TTL？

如果2.太低，无论订户的QoS或值是3，邮件都将从目的地过期。

如果3.太低且NodeRED停止的时间足够长，则整个目的地都已过期。