1

我正在尝试在 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()，并且流使用的任何消息现在都被确认 OK，即使 Node-RED 在发布时没有运行。该消息由 MQ Light 保存，因为目标上有一个 TTL，并且在我再次启动 Node-RED 时立即到达。

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

4

1 回答 1

2

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

我刚刚尝试了相同的基本设置（没有 NodeRED），并且行为如您所料 - 当您重新连接接收客户端时，MQ Light 重新传递消息并且 MQ Light UI 将其勾选。

我能想到的剩下的事情是：

  1. 发送该特定消息时，您是否有可能订阅了 QoS 0？
  2. 你在发件人的消息上设置了什么 TTL？
  3. 您在订阅呼叫中设置了哪些目标 TTL？

如果 2. 太低，则无论订阅者的 QoS 或 3 的值如何，消息都会从目的地过期。

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

于 2015-09-18T14:00:20.777 回答