MQ Light 中的重新发送行为
Resend behavior in MQ Light
我正在 MQ Light 中试验保证交付。
我将 Node-RED 与修改后的 mqlight 输入节点一起使用。我在 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()，并且流消耗的任何消息现在都被确认为 OK，即使 Node-RED 在 运行发布。该消息由 MQ Light 保留，因为目标上有一个 TTL，并且一旦我再次启动 Node-RED 就会到达。
然而，此屏幕截图中的消息已发送一次但从未确认，因此永远不会重发。重新启动 Node-RED 不会改变这一点，消息仍未决。为了让 MQ Light 重新传输之前已发送但从未得到客户端确认的消息，需要满足哪些条件？
如果您没有重新启动 NodeRED，我会说那是因为 MQ Light 不会重新传送到连接的客户端，因为它认为客户端仍在处理消息。但是既然你有它一定是别的东西。
我刚刚尝试了相同的基本设置（没有 NodeRED）并且行为如您所料 - 当您重新连接接收客户端 MQ Light 重新传送消息并且 MQ Light UI 勾选它关闭。
剩下我能想到的是：
- 发送特定消息时您的 QoS 是否可能为 0
订阅？
- 您为发件人的邮件设置的 TTL 是多少？
- 您在订阅呼叫中设置了什么目标 TTL？
如果 2. 太低，无论订阅者的 QoS 或 3 的值如何，来自目的地的消息都将过期。
如果 3. 太低并且 NodeRED 停止的时间足够长，则整个目标将过期。
我正在 MQ Light 中试验保证交付。
我将 Node-RED 与修改后的 mqlight 输入节点一起使用。我在 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()，并且流消耗的任何消息现在都被确认为 OK，即使 Node-RED 在 运行发布。该消息由 MQ Light 保留，因为目标上有一个 TTL，并且一旦我再次启动 Node-RED 就会到达。
然而，此屏幕截图中的消息已发送一次但从未确认，因此永远不会重发。重新启动 Node-RED 不会改变这一点，消息仍未决。为了让 MQ Light 重新传输之前已发送但从未得到客户端确认的消息，需要满足哪些条件？
如果您没有重新启动 NodeRED，我会说那是因为 MQ Light 不会重新传送到连接的客户端，因为它认为客户端仍在处理消息。但是既然你有它一定是别的东西。
我刚刚尝试了相同的基本设置（没有 NodeRED）并且行为如您所料 - 当您重新连接接收客户端 MQ Light 重新传送消息并且 MQ Light UI 勾选它关闭。
剩下我能想到的是：
- 发送特定消息时您的 QoS 是否可能为 0 订阅？
- 您为发件人的邮件设置的 TTL 是多少？
- 您在订阅呼叫中设置了什么目标 TTL？
如果 2. 太低，无论订阅者的 QoS 或 3 的值如何，来自目的地的消息都将过期。
如果 3. 太低并且 NodeRED 停止的时间足够长，则整个目标将过期。