問題タブ [spring-rabbit]

シナリオ（私は物事を単純化しました）：

• 多くのエンド ユーザーは、フロント エンド Web アプリケーション (プロデューサー) からジョブ (たとえば、大きな PDF のレンダリングなどの重いジョブ) を開始できます。
• ジョブは、単一の永続的な RabbitMQ キューに送信されます。
• 多くのワーカー アプリケーション (コンシューマー) がこれらのジョブを処理し、結果をデータストアに書き戻します。

このかなり標準的なパターンは正常に機能しています。

問題: ユーザーが同じ 1 分間に 10 個のジョブを開始し、その時間帯に稼働しているワーカー アプリケーションが 10 個しかない場合、このエンド ユーザーは事実上、すべての計算時間を自分自身のために取っています。

質問: エンド ユーザーごとに常に 1 つのジョブのみが処理されるようにするにはどうすればよいですか? (おまけ: 一部のエンド ユーザー (管理者など) は調整してはなりません)

また、エンド ユーザーが同時にジョブを開始するのをフロント エンド アプリケーションがブロックしないようにします。エンドユーザーには、並行ジョブが一度に 1 つずつ終了するのを待ってもらいたいだけです。

ソリューション？: エンド ユーザーごとに 1 つの自動削除専用キューを動的に作成する必要がありますか? はいの場合、ワーカー アプリケーションにこのキューの使用を開始するように指示するにはどうすればよいですか? 1 つ (そして 1 つだけ) のワーカーがこのキューから消費するようにするにはどうすればよいですか?

ここでのスタックオーバーフローでの最初の質問です。私はSpring AMQPを含むプロジェクトに取り組んでいます。開発のために、私はこのチュートリアルを見つけました：Spring AMQP Example

ListenerContainer クラスを実行すると、次の例外が発生します。

1. 原因: org.springframework.amqp.AmqpIllegalStateException: デフォルトのリスナーメソッドが指定されていません: 「defaultListenerMethod」プロパティに null 以外の値を指定するか、「getListenerMethodName」メソッドをオーバーライドしてください。

解決策を探していますが、解決できません。

誰かが私を助けることができれば、私は感謝します.

Spring-AMQP で Transactionnal RabbitMQ チャネルを使用しようとしていますが、実際に例外を飲み込んでログに記録し、それらを回復できるようにしたいと考えています。

channelTransacted=true を使用すると、Channel が強制的に現在の transactionManager (私の場合は Hibernate) にも参加するようになり、その結果、commit Exception が @Transactionnal 境界から再スローされ、上位レベルでエラーが発生し、それをキャッチしてログに記録することができなくなります。それ。

また、パブリッシュをトランザクションに手動でアタッチして、コミットが成功した後にのみ実行されるようにしました。

そのように使用されます:

しかし、その場合、channelTransacted=true を使用することはできません。これは、registeringSynchronization を別の registeringSynchronization 内にネストし、まったく呼び出されないためです...

これを達成する方法はありますか？

更新: 理想的には、 ConnectionFactoryUtils クラスで使用される RabbitResourceSynchronization をオーバーライドしたいのですが、これはファクトリがインスタンス化されていないプライベート クラスです。

RabbitMQ にメッセージを送信するための REST API を作成しており、チャネルを作成/閉じるためのベスト プラクティスを理解しようとしていました。RabbitMQ Java クライアント API を使用しています。

RabbitMQPublisherConnection現在、 RabbitMQ 接続をスプリング注入するクラスがあります。このクラスは、別のクラスにスプリング注入されRabbitMQPublisherChannelます。このクラスには、チャネルを作成する次の関数があります。

RabbitMQPublisherこれで、 Spring Injectクラスの 3 番目のクラスが作成されましたRabbitMQPublisherChannel。私のアプリケーション コンテキストは次のようになります。

このクラスRabbitMQPublisherには、RabbitMQ にメッセージを発行する機能があります。

このアプリケーションは tomcat を介して実行されますが、AppDynamics でチャネルを閉じるのに、メッセージの発行にかかる合計時間の 47% がかかることに気付きました。チャネルを閉じる呼び出しを削除すると、この 47% の時間を 32 ミリ秒節約できますが、RabbitMQ 管理コンソールで、その接続のチャネル数が増加していることに気付きます。

だから私の質問は -

1. tomcat が 1 秒あたり複数のリクエストを受け取ると仮定して、パブリッシュのたびにチャンネルを開閉するのは良い方法ですか?
2. これは複数のスレッド間でチャネル プールを共有することをお勧めしますか ( RabbitMQ はこれを推奨していますが、次のようにも述べていますEven so, applications should prefer using a Channel per thread instead of sharing the same Channel across multiple threads.)。これは、スレッドごとに新しいチャネルを作成することを意味しますか?
3. チャネルを閉じず、アイドル状態の RabbitMQ http api クリーンアップ チャネルを使用することをお勧めします。（これをお勧めしないでください）？
4. 32ミリ秒節約する価値はありますか？

ありがとう

Spring Integration、Websocket、RabbitMQ サーバーを使用してデモ チャット アプリケーションを開発しています。単一サーバーでアプリケーションを実行すると、正常に動作します。

プロデューサーによって送信されたすべてのメッセージは、コンシューマーによって受信されます。しかし、クラスター化された環境で実行すると、メッセージはサーバーでランダムに受信され、すべてのサーバーで受信されるわけではありません。

自分のコードに問題があるのか​​、構成が原因なのかはわかりません。

ロガーで確認してみました。ロガーは、メッセージが正常に送信されたが、すべてのサーバーで受信されたわけではなく、1 つのサーバーのみで受信されたことを示しています。

以下は、構成とともに使用しているクラスです。

ChatController.java

}

RandomDataGenerator.java

}

webapp-config.xml

プロキシ サーバーの構成

以下は、問題の原因をテストして試すことができるサンプル アプリケーションのリンクです。

デモ申し込み

私は最近、Spring と spring-amqp の学習を始めたので、この質問は非常に基本的なものに見えるかもしれません。

異なるホスト上にあり、異なる QueueName、RoutingKey、vhost、user、password を持つ複数のキューがあります。これらのキューのパブリッシング ロジックを作成していますが、キューごとに 1 つの構成クラスを使用する必要があるのか​​、それとも XML で実行できるのかを判断できませんでした。

キューに関するすべての情報 (ホスト、仮想ホスト、ユーザー名など) を持つクラスを作成する方法は、この例で説明されているように正常に機能しています。@Configuration クラスを作成し、そのキューのすべての Bean を定義しました。しかし、私はする必要があります

だから私の要件は次のとおりです。

1. アプリケーションの起動時にインスタンス化する必要がある多くのキューがあるため、Tomcat が起動したら、キュー/ウサギ クラスタへの接続/チャネルを確立する必要があります。
2. 次に、アプリケーションに POST リクエストが来るとすぐに、POST パラメータに基づいてキューの 1 つにメッセージを発行する必要があります。

したがって、キューごとに常に次のことを行う必要があります。

または、すべてのキュー構成クラスをSpringでロードし、次のようなオブジェクトを使用する方法はありますか:

1. では、毎回実行せずに正確なキューの amqpTemplate を取得するにはどうすればよいnew AnnotationConfigApplicationContext()でしょうか?
2. サービスにリクエストが来るたびに新しい AnnotationConfigApplicationContext を実行することの害は何ですか? [リクエストごとに新しいオブジェクトを作成するのは良い考えではないと推測しています]