java - JMS からの応答メッセージを読み取って収集し、正しいサーブレット スレッドで利用できるようにする方法は?

Question

非同期 JMS メッセージング システム用の同期 HTTP 要求応答フロント エンドがあります。

各 HTTPRequest の HTTP クエリ サーブレットは、対応する JMS メッセージをクエリ キューに作成します。このクエリはバックエンドによって処理され、このクエリに対していくつかの応答メッセージが作成されます。JMS で応答メッセージの受信を整理し、それらが適切なサーブレット スレッドに到達して HTTPResponse を作成できるようにするための適切な方法は何ですか?

クエリと応答は非トランザクションであり、永続化する必要はありません。それらのほとんどは読み取りクエリです。45 秒以内に応答が読み取られない場合、サーブレットはタイムアウト応答を生成します。ただし、スループットは重要です。ますます多くのクエリを処理する必要があります。このシステムは約 10 年前のもので、あと 2 年ほど稼働し続ける必要があります。

SonicMQ を使用しています。すべての応答に対して 1 つのキューを作成しました。サーブレット コンテナーには、読み取りと書き込みの両方に使用するブローカーへの接続が 1 つあります。ログインしたユーザーごとに 1 つのリスナー スレッドを生成します (約 1500 の同時実行)。このスレッドには、この特定のユーザーの応答メッセージのみを選択するメッセージ セレクターを備えた受信機があります。サーブレット スレッドがクエリ メッセージを送信すると、ユーザーのリスナー スレッドが応答を読み取ったことを通知するまで待機します。

以前は、すべての送信者とすべての受信者が 1 つの QueueSession を共有していました。セッションは公式にはスレッドセーフではありませんが、これは実際に機能しました(!)。スレッド (サーブレット スレッドとリスナー スレッド) ごとに 1 つの QueueSession を作成すると、パフォーマンスがいくらか改善されましたが、それでもまだ安定していません。

メッセージセレクターを備えた単一のキューではなく、ユーザーセッションごとに一時キューを作成しようとしましたが、かなり遅くなりました。

これを整理するためのより良い/適切な方法は何でしょうか?

Answer 1

私はこれをコメントとして始めましたが、ちょっと成長しました。

あなたの説明から、すべてのリクエストには少なくとも 2 つのスレッド、場合によってはそれ以上のスレッドが必要であるように思えます。すでに 1500 人の同時ユーザーがいて、クエリが他のノードにファームアウトするのに十分な作業である場合、アクティブなスレッドがどれだけ多くのアクティブなスレッドが実行されるかについては、すでに危険な領域に入っていると言えます。多額のCPU /メモリ割り当てと設定の深刻な微調整のないJVM。

JMS の削除についての私のコメントは、アプリケーションのサーブレット側から見ると、JMS を同期要求/応答メカニズムにするために多くの余分な作業を行っているだけであり、単純なスレッド プールが実行できるのと同じように機能するためです。 HTTP 要求に応答する複数の同時クエリ。ただし、JMS はバックエンドが作業要求を受信する適切な方法のように思えますが、大幅な書き直しはおそらく意味がありません。

これを整理するより良い方法は、リクエストスレッドごとのコンシューマーではなく、Tomcat インスタンスごとのコンシューマーのセットになると思います。各 Webhead は独自の応答キューを持つか、単一のキューで MessageSelectors を使用できます。次に、リクエストが着信したら、リクエスト JMS メッセージを送信し、発信者がtake()を待っているSynchronousQueueのように、コンシューマーが呼び出しスレッドにコールバックする方法を残します。1 つのリクエストを処理するために複数のメッセージを待機する必要がある場合は、ConcurrentLinkedQueueを組み合わせて、 CountdownLatchでレスポンスをドロップすることができます。応答がすべて受信されたときに、要求元のスレッドに通知します。このようにして、メッセージが着信したときにメッセージを受信する責任を負うスレッドのプールを比較的小さくすることができます。

その後もパフォーマンスに問題がある場合は、Tomcat インスタンスを追加するか、HTTP 要求処理の非ブロッキング IO を調べて、フロント ドアとバックドアに同じ戦略を適用してスケーリングできます。大量のリクエストを処理するためのスレッド。待機は、リクエストごとのスレッド モデルで多くのスレッドを拘束します。