問題タブ [spring-rabbit]

私は、データがキューに存在するたびにデータをリッスンしてデキューするスプリングフレームワークとrabbitMQを使用するアプリケーションで作業しています。私が望むのは、処理中にリスナーを強制終了することはできず、リッスン中にのみ強制終了でき、キューにデータが存在しないことです。それで、誰かそれについて何か考えがありますか？出来ますか？もしそうなら、私は何をすべきですか？
ありがとう

私はこれを達成しようとしています。それが可能かどうかを知るには、非常に多くの相反する答えがあります。

前のリンクによると、それは不可能です。しかし、このフォーラムの別の質問で、誰かがこことここのコメント セクションでできたと述べました。

それで、 live queue => dead-letter-queue => live queue を行うことは可能ですか

または、これを実現するために特定のバージョンの RabbitMq を使用する必要がありますか?

私ができること: live queue => dead-letter-queue および dead-letter-queue => live queue.

Tomcat をシャットダウンすると、ログに次のメッセージが表示され、JVM はプロセスを解放しません。

デバッガーを使用して、シャットダウン前にこれらのスレッドが何をしているかを確認しました。これはスレッド ダンプの 1 つです。

これを、春/春ウサギがこの問題の原因であるという証拠として使用しています。

これは、ウサギの mq に関係する私の Spring コンテキストの一部です。

Tomcat をシャットダウンするときに作成されたスレッドを停止するように spring-rabbit に指示するにはどうすればよいですか?

spring-rabbit バージョン 1.4.2.RELEASE を使用しています

ここで何が欠けているのかわからず、解決策を探すことができませんでした。この問題の解決にご協力ください。感謝します。

Jboss EAP 6.3.0 で実行されています。サーバーを起動すると、ログがローリングし続けるため、強制的に停止する必要があります。ログは秒単位で 20000kb ～ 30000kb までロールアップされます

Spring コンテキスト xml は次のとおりです。

以下は、pom.xml のスナップショットです。

編集：

1. スキーマ内のすべてのバージョン番号を削除しました。

2. AMQP バージョン:

rabbitmq.バージョン 3.1.1

spring.amqp.version 1.1.4.RELEASE

3. 最近、webapp (web.xml) を 2.4 から 3.0 に変更しました。それは問題でしょうか。変更前に機能するかどうかはテストしませんでした。これは問題になりますか？

編集: 以下のこれらのエラーは、エラーに表示されなくなりました。唯一のエラーは、一致するワイルドカードです

4. ログにさらにいくつかのエラーが表示されます (繰り返し発生します)。これらのエラーも以前に発生しました。

(ServerService スレッド プール -- 60) JBWEB000287: クラス com.sun.faces.config.ConfigureListener のリスナー インスタンスにコンテキスト初期化イベントを送信中に例外が発生しました: java.lang.IllegalArgumentException: JBAS011857: NamingStore is null org.jboss.as.naming.NamingContext.(NamingContext.java:152) で org.jboss.as.naming.NamingContext.(NamingContext.java:125) で org.jboss.as.naming.InitialContext$DefaultInitialContext.( InitialContext.java:182) org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:117) org.jboss.as.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:154) javax.naming.InitialContext .lookup(InitialContext.java:411) [rt.jar:1.7.0_51] javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_51] com.sun.faces.config .WebConfiguration.processJndiEntries(WebConfiguration.java:702) [jsf-impl-2.1.28.redhat-3.jar:2.1.28.redhat-3] com.sun.faces.config.WebConfiguration.(WebConfiguration.java: 134) [jsf-impl-2.1.28.redhat-3.jar:2.1.28.redhat-3] com.sun.faces.config.WebConfiguration.getInstance(WebConfiguration.java:194) [jsf-impl-2.1.28.redhat-3.jar:2.1.28.redhat-3] com.sun .faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:158) [jsf-impl-2.1.28.redhat-3.jar:2.1.28.redhat-3] at org.apache.catalina.core.StandardContext.contextListenerStart (StandardContext.java:3339) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] org.apache.catalina.core.StandardContext.start(StandardContext.java:3777) ) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at org.jboss.as.web.deployment.WebDeploymentService.doStart(WebDeploymentService.java:161) [jboss- as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] org.jboss.as.web.deployment.WebDeploymentService.access$000(WebDeploymentService.java:59) [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] org.jboss.as.web.deployment.WebDeploymentService$1.run(WebDeploymentService.java) :94) [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471 で) ) [rt.jar:1.7.0_51] at java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_51] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java) :1145) [rt.jar:1.7.0_51] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51] at java.lang.Thread.run(Thread) .java:744) [rt.jar:1.7.0_51] at org.jboss.threads.JBossThread.run(JBossThread.java:122)jboss.as.web.deployment.WebDeploymentService$1.run(WebDeploymentService.java:94) [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] at java .util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_51] java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7. 0_51] java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) で [rt.jar:1.7.0_51] java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) で [rt.jar:1.7.0_51] jar:1.7.0_51] at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] at org.jboss.threads.JBossThread.run(JBossThread.java:122)jboss.as.web.deployment.WebDeploymentService$1.run(WebDeploymentService.java:94) [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] at java .util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_51] java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7. 0_51] java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) で [rt.jar:1.7.0_51] java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) で [rt.jar:1.7.0_51] jar:1.7.0_51] at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] at org.jboss.threads.JBossThread.run(JBossThread.java:122)concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_51] で java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_51] でjava.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51] java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7] .0_51] で java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] で org.jboss.threads.JBossThread.run(JBossThread.java:122)concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_51] で java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_51] でjava.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51] java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7] .0_51] で java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] で org.jboss.threads.JBossThread.run(JBossThread.java:122)run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51] at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] at org.jboss.threads.JBossThread.実行 (JBossThread.java:122)run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51] at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] at org.jboss.threads.JBossThread.実行 (JBossThread.java:122)

この：

私のプロジェクトでは、さまざまな方法でSQLクエリをRabbitキューにプッシュする（基本的には、メッセージをすべてのキューにブロードキャストする交換）などの要件があります。キューにプッシュされたこれらの SQL クエリは、現時点では (基本的にはレポート目的で) 本番環境と比較するとあまり重要ではないため、サーバーに多くの負荷がかからないときに、これらのクエリを別の環境 (他のスタンドアロン プロジェクト) で実行します。 .

では、ストーリーの第 2 部に入りましょう。反対側のスタンドアロン アプリケーションには、RabbitMQ (交換) からのメッセージ (SQL クエリ) を消費する 2 つのコンシューマーがあります。1 つのコンシューマーは常にログを記録し (クエリのバックアップなど)、他のコンシューマーは DB でバッチ更新/挿入を実行します。

私の問題は、いくつかの理由でいくつかのクエリが失敗する可能性があり、バッチ操作であるため、バッチ全体がロールバックされ、それらが既に消費されているためキューから再度取得できない場合に、このユースケースを達成するための良い方法です。2 番目のコンシューマによって作成されたバックアップから取得する必要があることはわかっていますが、例外が発生した後に最初のコンシューマを停止する必要があり、その特定の失敗したクエリをバックアップ ログからフェッチする良い方法は何ですか (クエリの不足を考慮して、考えています)複数のログ ファイルにローリング アペンダー ログを使用する方法)。私の問題を辛抱強く理解してくれてありがとう。この問題を解決する良い方法を提案してください。

正しく構成された RabbitMQ キューのように見えるもの (dlx 引数を表示) があり、Java リスナー コードでFatalListenerExecutionException. 何らかの理由で、例外がスローされた後、指定された配信不能キューに何も表示されません。

間違った種類の例外をスローしていますか?

ありがとう。

Spring 構成でのキューのインスタンス化:

Spring 構成のリスナー コンテナー:

RabbitMQ コンソールに表示される「some.queue」のバインディング:

私が維持しているプロジェクトで、RabbitMQ キューを起動する一連のテストを実行しています。私が知る限り、RabbitMQ キューとはまったくやり取りしていません。しかし、定期的にShutdownSignalException、テストに影響を与えると思われる を取得します。com.rabbitmq.client.impl.AMQConnection#startShutdownメソッドのブレークポイントのイメージを次に示します。

コードのどの部分がこの例外をトリガーしているかを調べるにはどうすればよいですか? また、自分のコードがこのキューを使用していないことをどのように確信できますか? ブレークポイントを設定できる RabbitMQ コードの特別な部分はありますか?

Spring RabbitMQ バージョン 1.3.5.RELEASE を使用してキューを構成しています。私は RabbitMQ についてあまり詳しくないので、他に提供すべき情報があれば教えてください。