Jboss Messaging WorkerThread # что это за темы?

Я загружаю тестовую установку обмена сообщениями jboss с 5 производителями, производящими 100 000 сообщений 100 тыс. Сообщений. Я вижу значительные узкие места. Когда я отслеживаю профилировщик, я вижу, что существует 15 потоков с именем WorkerThread #. Эти потоки распределяются на 100% без ожиданий. Я думаю, они могут быть связаны. Кто-нибудь знает, какая функция работает в этих потоках, и если есть параметр threadpool. Я использую зиррJboss Messaging WorkerThread # что это за темы?

JBoss Enterprise Application Server 4.3 CP08
JBoss Enterprise Service Bus 4.4 CP04
JBoss Сделки 4.2.3._CP07
JBoss Messaging 1.4.0.SP3-CP09
JBoss Правила 4.0.7
JBoss jBPM 3.2.9
JBoss Web Services 2.0.1.SP2_CP07

источник

2010-12-06 nsfyn55

Если вы производите 100 000 сообщений по 100 тыс. Каждый, почему вы удивлены тем, что у вас есть несколько потоков, работающих на полном дросселе? Конечно, это хорошо. – skaffman 2010-12-06 22:22:41

Конечно. Но мое оборудование не используется. Это должен быть пул, потому что, когда сервер работает на холостом ходу, только 3 из них при распределении 0%, то он достигает 15 на 100%. Затем мои ответы время вниз по pooper.Seems, как я мог бы просто использовать пул. Я хотел бы запустить некоторые bencmarks с большим количеством потоков в пуле. – nsfyn55 2010-12-07 15:53:33

Я понял это. Это не пул нитей. В файле jboss-messaging.sar/remoting-bisocket.xml, который определяет соединительный разъем для Jboss Messaging, вы видите несколько значений, главным образом, clientMaxPool, maxPoolSize, numAcceptThreads.

При удалении, когда установлен сокет, создаются потоки для контроля этого сокета до значения «numAcceptThreads». Весь этот поток выполняет чтение данных из сокета и передает его потоку в пуле клиентов (управляется maxPoolSize).

Нитки, называемые workerThread # [], относятся к потокам accept. Причина, по которой я вижу больше, когда я создаю больше продюсеров, заключается в том, что для транспорта bisocket для Jboss Messaging, по-видимому, создано три сокета. Первоначально есть 3, но когда я создаю 5 продюсеров, число увеличивается до 15 (или 5 * 3 для тех, кто не математически склонен :)). Причина, по которой они на 100% распределены, заключается в том, что, когда я отправляю все эти сообщения, потоки, считанные из сокета, передаются в серверную нить, возвращайтесь к чтению из сокета (где это всегда данные)

Итак, короткий Ответ: нет пула для управления этими потоками. У вас может быть более 1 прием потока, но это почти никогда не имеет смысла. Это потому, что его работа настолько минимальна, чтобы читать данные, передавать их, читать данные ... Так что больше потоков просто добавит накладные расходы синхронизации.

источник

2010-12-07 20:04:05 nsfyn55

-1

Это из http://download.oracle.com/javase/tutorial/uiswing/concurrency/worker.html; Надеюсь, поможет.

Когда программе Swing необходимо выполнить долговременную задачу, она обычно использует один из рабочих потоков, также известный как потоки фона. Каждая задача, выполняемая на рабочем потоке, представлена экземпляром javax.swing.SwingWorker. Сам SwingWorker является абстрактным классом; вы должны определить подкласс для создания объекта SwingWorker; анонимные внутренние классы часто полезны для создания очень простых объектов SwingWorker.

источник

2010-12-07 19:09:29

Jboss Messaging WorkerThread # что это за темы?

ответ

Смежные вопросы