1) 2) クライアント デスクトップで実行される Java SWING アプリケーション/アプレットに応答するカスタム サーバー (従来の ServerSocket) を持つアプリケーションがあります。
このようなカスタム サーバーは 140 台以上あります (Swing クライアントの各グループ専用)。サーバーの起動、シャットダウンなどを管理するための管理アプリケーションを構築しました。管理アプリとサーバー間の通信のために、JMS アプリケーションを構築しています。サーバーへの負担が大きいため、この JMS を同じボックスに配置していないため、別の JMS ボックスを用意するオプションが残されています。サーバーごとに個別のキューが必要です。
私の質問は、1 つのアプリケーション サーバーで 140 以上の JMS キューを使用できるかということです。はいの場合、ハードウェアの理想的な構成は何ですか。いいえの場合、何を提案しますか。
ありがとう
私はこの興味深い記事を少し前に見つけました：
[ActiveMQ]開いているファイルが多すぎるため、ノードで700個のキューを開いた後、ブローカーが失敗します。明らかに、各キューに一時ファイル、各JARに開いているファイル（124個あります！）、および60個のその他のファイルハンドルがあります。クライアントが終了しても、開いているファイルの数は減りません。いくつかのグーグルは、リークされたファイルハンドルに関連するActiveMQに多数のバグがあることを意味します。
(各クライアントに固有のメッセージをプルするために)より少ないキューとメッセージ セレクターを使用するか、このページを参照して、多数のキューを処理するように ActiveMQ を構成することができます...
また、KahaDB 5.3+ を使用している場合は、より少ないファイル記述子などを使用するように最適化されています...
「ない場合」の部分だけお答えします。
必要に応じて、メッセージ セレクターを使用してキュー カウントを減らすことができます。サーバーのグループは、1 つのキューに送信でき、メッセージ プロパティによって識別されます。サーバーを一意に識別する IP、URL を既に定義しておく必要があります。
ただし、別のキューをより適切に監視できるため、これは最後の手段です。