0

私たちはここ数週間HornetQを研究しています。

私たちのビジネスには多くの「デルタ」メッセージがあり、(残念ながら...)それらはバージョン管理されていません(これは国際標準であるため、バージョン管理されません)。これは、明らかに、同じメッセージを2回送信することは眉をひそめることを意味します。それでも、標準はそれを実際に回避することはできないことを認めており、この場合、メッセージに重複の可能性があるとしてフラグを立てるように送信者に指示します。

HornetQのドキュメントをページングすると、サーバーが受信した重複の回避について多くのことが説明されていますが、重複の作成を回避することについては何も見つかりませんでした。

より明確にするために、次の状況を想定します。

  • 1台のHQサーバー
  • 1消費者

通常のシナリオでは、コンシューマーはキュー内のメッセージを取得してサードパーティに送信し、確認応答を受信したら、サーバーにメッセージを確認してキューから削除します。

さて、ここでの弱点はackの部分です。サードパーティがメッセージを受信して​​処理したが、(何らかの理由で)ackが失敗し、メッセージがデキューされていない可能性があります。

本社はメッセージが完全に配信されたことを知ることはできませんが、配信がすでに試行されていること、およびメッセージが重複する可能性があることを認識していると思います。サードパーティが懸念しています。

メッセージに適切にフラグを立てられるように、このおそらくすでに配信されたステータスについてコンシューマーに通知する方法はありますか?

4

1 に答える 1

2

これを行う1つの方法は、NACを送信することです(または、指定された期間内にメッセージがサードパーティによって確認されなかった場合は、HornetQにエラーをスローバックします)。HornetQのキューがmax-delivery-attempts>0で構成されている場合、これによりメッセージが再配信されます。

その時点で、メッセージのヘッダーは、パラメーター「JMSXDeliveryCount」についてHornetQクライアントによってイントロスペクトできます。これは、メッセージが初めて送信されるのか、再配信されるのかを示します。

ここに示す方法は、HornetQクライアントがメッセージの消費にJMSAPIを使用することを前提としています。コアAPIにも同等のものがあると確信しています。

于 2012-04-05T14:28:40.633 に答える