問題タブ [spring-jms]

ActiveMQ 5.5.1 を使用して、ブローカーのネットワークとして構成されたブローカーのペアがあります。各ブローカーは、WAN を介して通信するサーバー上に存在します。

ServerA 上の BrokerA

ServerB の BrokerB

各サーバーで、次のトピックとキューを作成する Java サービスを実行しています。

Java サービス (各サーバー上) は、 myQueue のプロデューサーとコンシューマー、およびmyTopicのプロデューサーとコンシューマーを作成します。myTopicの両方のコンシューマーがすべてのトピック メッセージを受信するようにします。問題はmyQueueにあります。構成されたものだけが欲しいmyQueueメッセージを消費するブローカー。たとえば、BrokerA が ServerA でサービス メッセージを生成する場合、ServerB の BrokerB のみがそのメッセージを消費するようにします。現在、私のテストでは、ServerA で生成されたメッセージの約 50% が BrokerA によって消費され、50% が BrokerB によって消費されていることがわかります。さらに、BrokerB がオフラインになった場合、BrokerA はServerA と ServerB の両方からのすべてのmyQueueメッセージを受け入れ、BrokerB がオンラインに戻るまですべてのmyQueueメッセージを消費する必要があります。

メッセージグループを利用することも考えたのですが、メッセージの送信先グループの切り替えに失敗した場合の検出方法がうまく思いつきませんでした。任意の推奨事項をいただければ幸いです。

次のテストでは、次のシナリオをシミュレートしようとしています。

1. メッセージキューが開始されます。
2. メッセージ処理中に失敗するように設計されたコンシューマーが開始されます。
3. メッセージが生成されます。
4. コンシューマーはメッセージの処理を開始します。
5. 処理中に、メッセージ処理の失敗をシミュレートするために例外がスローされます。失敗したコンシューマーは停止します。
6. 別の消費者は、再配信されたメッセージを受け取ることを目的として開始されます。

しかし、私のテストは失敗し、メッセージは新しいコンシューマーに再配信されません。これに関するヒントをいただければ幸いです。

MessageProcessingFailureAndReprocessingTest.java

TaskListener.java

MockTaskProducer.java

Spring を使用してトピックをサブスクライブする正しい方法は何だろうか。

DefaultMessageListenerContainer非永続サブスクリプションを使用してを試しましたが、ほとんどの場合失敗します。未解決のバグ ( SPR-7833 ) があり、非永続トピック サブスクリプションでは機能しないことが指摘されているようです。

障害が発生した場合に自動再接続をサポートする DMLC に代わるものはありますか?

ところで、私はプログラムで DMLC を作成しており、自動再接続のために Failover Transport を使用して組み込みの ActiveMQ 5.5.1 ブローカーに接続しています。キューからのメッセージの消費は、最も奇妙なシナリオでも期待どおりに機能しますが、トピックではうまくいきません。

このアプリケーションでは、JMSトピックからメッセージを受信します。

• まず、JMSがFIFOポリシーに従っているかどうかを知りたいです。そうでない場合、アプリケーションはどのようにして最新のメッセージを判別できますか？

メッセージはトランザクションがコミット/終了するまでJMSサーバーに保持されるため、メッセージを消費します（永続サブスクライバーとJMSセッションはトランザクション処理され、多くのオーバーヘッドが発生します）。トランザクションを指定した理由は

• キャッシング（休止）テクノロジーとそれを使用するトランザクションを使用しています。したがって、2つのトランザクションを使用しています。1つはJMS txで、もう1つはキャッシングテクノロジーtxです。メッセージを消費し、メッセージがコミットされて確認応答がJMSに送信されるまで、すべてまたは何も起こらないようにしたい場合。txをキャッシュすると、最初にコミットされ、すぐにJMS txが次にコミットされ、メッセージが確認されます。それ以外の場合は、両方のtxがロールバックされ、メッセージが再生されます。現在、メッセージを3回再生していますが、それでも例外が発生する場合は、メッセージを処理不可能なキューに送信しています。

• これは、多くのメッセージが同時にJMSに届き、システムで同時に処理する必要があるまでは正常に機能します。

• そのようなシナリオに遭遇したとき、あなたは何をしましたか？なぜなら、永続的なサブスクリプションとトランザクションセッションを維持することは、JMSサーバーよりも大きなオーバーヘッドであり、サーバーのパフォーマンスを低下させるからです。

Spring Message Listener Container doc は次のように述べています。

http://static.springsource.org/spring/docs/2.5.x/api/org/springframework/jms/listener/AbstractMessageListenerContainer.html#setDurableSubscriptionName%28java.lang.String%29

永続サブスクリプション名は、このクライアントの JMS クライアント ID 内で一意である必要があります。デフォルトは、指定されたメッセージ リスナーのクラス名です。注: 永続サブスクリプションごとに 1 つの同時コンシューマー (このメッセージ リスナー コンテナーのデフォルト) のみが許可されます。

並行メッセージを同時に処理できると思いました。何か不足していますか？

私には3人のクライアントがいます。各クライアントがオンラインである場合とJMSに基づいていない場合（JavaメッセージングとTomcatサーバー）を表示するアプリケーションを作成したいと思います。これまで、JMS（queue1）を使用して送受信メッセージを作成することに成功しました。

アプリケーションを存続させるためにどこから始めればよいのかわかりません。

ありがとうございました。助けが必要。感謝！

spring-jms-3.0.6.RELEASEを使用してMQを開きます。以下の例外が発生する理由について何かアイデアはありますか？

web.xml：

testlistener-context-api.xml：

testmsg-context-api.xml：

xml構成を使用せずにこれを行いたいです。Spring JMS をいじって、自分のニーズを満たすかどうかを確認しています。を使用して同期受信を行う方法はありますか

純粋な JMS 呼び出しと同等になるようにします。

xml を使用して構成する必要はありませんか?

私のSpringプロジェクトには、Springによって管理されるJMSメッセージリスナーがあります。

ある特定のメッセージで、リクエストスコープのSpring MVCコントローラーを呼び出す必要があります（実際の目標は、リクエストスコープでコントローラーによって呼び出されるサービスを呼び出すことです）。したがって、Springが必要に応じてそれらを管理し、スコープにバインドされていないため、リスナーから直接それを行うことはできません（そのため、@Autowireまたはを介してコントローラーにアクセスできませんApplicationContext）。解決策の1つは、コントローラーによってマップされたRESTテンプレートからURLへのHTTP呼び出しである可能性があります。しかし、私はその種のオーバーヘッドだと思います。それで、HTTPプロトコルのオーバーヘッドを回避し、Spring MVCフレームワーク内でControllerを呼び出す他の方法があるのではないでしょうか？

設定されているシステム環境変数に応じて、Spring Bean をロードする最良の方法を見つけようとしています。これはプロファイルを使用した簡単な作業であると認識していますが、残念ながら私は Spring 2.5 を使用しています。したがって、ここに私の XML ファイルの Bean 定義があります。

基本的に、システム環境変数の存在に基づいてその Bean のみをロードする方法を探しています。それ以外の場合は無視します。私は BeanPostProcessors と BeanFactoryPostProcessors の使用を検討してきましたが、解決策を完全に理解することはできません。これに関するヘルプは大歓迎です。ありがとう！