100,000 100k メッセージを生成する 5 つのプロデューサーで jboss メッセージング インストールの負荷テストを行っています。重大なボトルネックが発生しています。プロファイラーを監視すると、WorkerThread# という名前のスレッドが 15 個あることがわかります。これらのスレッドは、待機なしで 100% 割り当てられます。それらが関係している可能性があると思います。これらのスレッドが提供する機能と、スレッドプール設定があるかどうかを知っている人はいますか。サプリを使っています
JBoss Enterprise Application Server 4.3 CP08
JBoss Enterprise Service Bus 4.4 CP04
JBoss Transactions 4.2.3._CP07
JBoss Messaging 1.4.0.SP3-CP09
JBoss Rules 4.0.7
JBoss jBPM 3.2.9
JBoss Web Services 2.0.1.SP2_CP07
私はそれを理解しました。スレッドのプールではありません。Jboss Messaging のリモーティング コネクタを定義する jboss-messaging.sar/remoting-bisocket.xml ファイルには、主に clientMaxPool、maxPoolSize、numAcceptThreads の値がいくつか表示されます。
リモート処理では、ソケットが確立されると、「numAcceptThreads」の値までそのソケットを監視するスレッドが作成されます。このスレッドが行うことは、ソケットからデータを読み取り、それをクライアント プール (maxPoolSize によって制御される) 内のスレッドに渡すことだけです。
workerThread#[] と呼ばれるスレッドは、受け入れスレッドを参照します。より多くのプロデューサを作成するとより多く表示される理由は、Jboss Messaging の bisocket トランスポートで明らかに 3 つのソケットが作成されるためです。最初は 3 つですが、5 つのプロデューサーを作成すると、その数は 15 に増えます (または、数学に傾倒していない場合は 5*3 :))。それらが100％割り当てられている理由は、スレッドがソケットから読み取ったすべてのメッセージを送信すると、サーバースレッドに引き渡され、ソケットからの読み取りに戻るためです（これは常にデータです）
したがって、簡単に言えば、これらのスレッドを管理するプールはありません。複数の受け入れスレッドを持つことができますが、ほとんど意味がありません。これは、そのジョブが非常に最小限であるため、データの読み取り、ハンドオフ、データの読み取り... したがって、スレッドを増やすと、同期のオーバーヘッドが追加されるだけです。
これはhttp://download.oracle.com/javase/tutorial/uiswing/concurrency/worker.htmlからのものです。それが役に立てば幸い。
Swingプログラムが長時間実行されるタスクを実行する必要がある場合、通常、バックグラウンドスレッドとも呼ばれるワーカースレッドの1つを使用します。ワーカースレッドで実行されている各タスクは、javax.swing.SwingWorkerのインスタンスで表されます。SwingWorker自体は抽象クラスです。SwingWorkerオブジェクトを作成するには、サブクラスを定義する必要があります。匿名の内部クラスは、非常に単純なSwingWorkerオブジェクトを作成するのに役立つことがよくあります。