0

IBM MQを使用しており、受信者への非同期配信の制御に関していくつかの深刻な問題に直面しています。いくつかのJavaリスナーが構成されていますが、サーバーに送信されるメッセージのため、リスナーに送信されるメッセージを制御する必要があるという問題があります。数百万の数であり、サーバーマシンには一度にそれほど多くのスレッドを処理するほどの容量がないので、ApacheMQのようにプリエッチング制限を構成できるIBMMQ側でスロットルのような方法はありますか？

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

現在、リスナーでX制限に達したときに、IBM MQとの接続を閉じていますが、効率的な方法ではないようです。

この問題を解決するために私たちを助けてください。

4

2 に答える 2

5

一般に、MQ のようなメッセージ キューイング テクノロジでは、キューのポイントは、送信者が受信者から切り離されることです。メッセージの量に問題がある場合の答えは、メッセージを受信者のキューに入れ、送信者を抑制しないようにして、できる限り処理することです。

明らかな答えは、リスナーが使用できるスレッドの最大数を制限することです。ある種の MQ スレッドプールを使用していると思いますか? 無制限のリスナー スレッドを提供する、どのプラットフォームを使用していますか?

あなたの説明から、キューでメッセージを検出するとすぐに、メッセージを読み取り、新しいスレッドを開始し、戻ってキューを再度見るプロセスが実行されているように思えます。これは間違ったアプローチです。

キュー自体から読み取る定義済みの数のプロセス スレッドを実行する必要があります (1 つから開始し、必要に応じてサーバーの制限内でスケールアップします)。MQRC 2033 を取得した場合 (キューにメッセージがない場合)、それらはそれぞれキューを共有モードで開き、get-with-wait またはスリープ付きの即時 get を実行します。

それが役立つことを願っています。

于 2011-07-19T06:57:42.673 に答える
0

アプリケーション サーバー環境で実行している場合、activationSpec の maxPoolDepth プロパティが MDB の最大 ServerSessionPool サイズを定義します。これを減らすと、同時に配信されるメッセージの数が抑制されます。

もちろん、MDB (または JSE 環境の javax.jms.MessageListener) がメッセージを別のものに渡すだけの場合 (または、さらに悪いことに、管理されていないスレッドを生成して開始するだけ)、onMessage が高速で回転し、引き続き遭遇する可能性があります。問題。したがって、その場合、スレッドプール構成などを介して、他のリソースも制限する必要があります。

MQCONN/MQDISC サイクルはコストがかかるため、QM への接続を閉じることは決して効率的な方法ではありません。

于 2011-07-19T08:39:27.100 に答える