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() を実行すると、発行時に Node-RED が実行されていなくても、フローによって消費されたすべてのメッセージが正常に確認されるようになりました。宛先に TTL があるため、メッセージは MQ Light によって保持され、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 に答える