2

ワーカー タスクをさまざまなサーバーに送信する ActiveMQ ベースのメッセージング サービスの実装を開始していますが、デフォルト モードでは、誰もプロデューサーのトピックを「リッスン」していない場合、そのプロデューサーからのメッセージが失われることに気付きました。

すなわち、

  • Producer が Live Broker を使用してメッセージを送信する場合
  • しかし、耳を傾ける消費者はいません
  • メッセージはどこにも行きません

代わりに、少なくとも 1 つのリスナーがメッセージを受信するまで、ブローカーがメッセージを保持するようにしたいと考えています。

私はこれを実装するいくつかの方法を試していますが、最も最適な/正しい方法についてはわかりません:

  • メッセージ確認機能を実装する
  • （これに対する注意点は、プロデューサーがすべてのメッセージの後にリスナーを待機する必要があることです。これは、非常に不格好で最後の手段と思われます...）
  • セッション トランザクションを実装する
  • （私はこれに問題があります。トランザクションという言葉のためにここで使用するのが正しいように聞こえますが、生産者と消費者ではなく、生産者とブローカーの相互作用に関係していると思います）

理想的には、メッセージ (または一連のメッセージ) を送信するモードがあり、送信後にブール値が返され、メッセージが少なくとも 1 つのコンシューマーによってリッスンされたかどうかが示されます。

4

2 に答える 2

1

トランザクションと確認応答は、JMS トピックの一般的な考え方と矛盾します。

トピックの代わりにキューを使用してください。CLIENT_ACKNOWLEDGEまたはトランザクション セッションを使用して、このキューにアクセスします。いずれにせよ、ワーカー タスクは 1 つのワーカーによってのみ処理されるため、キューは別の問題を解決します。

トピックを使用する特別な理由がある場合は、JMS プロバイダーのような同じホスト上のメッセージ駆動型 Bean (MDB) を考慮することができます (たとえば、統合された HornetQ で JBoss を使用することでこれを実現できます) が、これはまだ実際にはそうではありません。正しい。

もう 1 つの可能性は、トピックとキューの両方を持つことです。後者は、各メッセージの配信を保証するためだけのものです。

于 2013-09-26T07:03:07.057 に答える
0

これは、実際には典型的なメッセージング パターンではありません。通常、1 つのレシーバーと永続キュー、またはトピックへの永続サブスクリプションを持つ複数のレシーバーがあります。どちらの状況でも、各受信者は常にメッセージを受信します。「少なくとも1つの」受信者がそれを受信する必要があるユースケースがよくわかりません。

はい、トランザクションは、クライアントと最終的な受信者の間ではなく、クライアントとブローカーの間のやり取りのみを処理します。

于 2013-09-26T01:07:00.780 に答える