Повторное поведение в MQ Light

Question

Я экспериментирую с гарантированной доставкой в ​​MQ Light.

Я использую Node-RED с модифицированным входным узлом mqlight. Я добавил следующие опции на вызов подписки():

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

Это требует, чтобы я называю delivery.message.confirmDelivery(), чтобы признать в MQ Свету получение сообщения.

Снимок экрана ниже, когда подписка от mqlight_NodeREDClient настроена с использованием autoConfirm false, получено сообщение, НО не было вызвана доставка.message.confirmDelivery(). Это должно было имитировать некоторую ошибку, возникающую в потоке Node-RED.

С тех пор я изменил поток Node-RED для подтверждения доставки(), и все сообщения, потребляемые потоком, теперь подтверждены OK, даже если 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 было остановлено достаточно долго, весь пункт назначения будет истек.