Jboss Messaging WorkerThread # qu'est-ce que ces threads?

Je suis en charge de tester une installation de messagerie jboss avec 5 producteurs produisant 100 000 messages 100k. Je constate un important goulot d'étranglement. Lorsque je surveille le profileur, je vois qu'il y a 15 threads nommés WorkerThread #. Ces threads sont alloués à 100% sans attente. Je pense qu'ils peuvent être liés. Est-ce que quelqu'un sait quelle fonction ces threads service et s'il y a un paramètre de pool de threads. J'utilise un suppJboss Messaging WorkerThread # qu'est-ce que ces threads?

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
Règles JBoss 4.0.7
JBoss jBPM 3.2.9
JBoss Web services 2.0.1.SP2_CP07

Source

2010-12-06 nsfyn55

Si vous produisez 100 000 messages de 100 000, pourquoi êtes-vous surpris que plusieurs threads fonctionnent à plein régime? Sûrement c'est une bonne chose. – skaffman

Sure am. Mais mon matériel n'est pas exploité au minimum. Cela doit être un pool car lorsque le serveur est inactif, il n'y en a que 3 à 0% d'allocation, puis il passe à 15 à 100%. Puis mes temps de réponse descendent le pooper. On dirait que je pourrais juste être en train d'exploiter la piscine. Je voudrais exécuter quelques bencmarks avec plus de threads dans la piscine. – nsfyn55

Je l'ai compris. Ce n'est pas un pool de threads. Dans le fichier jboss-messaging.sar/remoting-bisocket.xml qui définit le connecteur distant pour Jboss Messaging, vous voyez une paire de valeurs principalement clientMaxPool, maxPoolSize, numAcceptThreads. Dans la communication à distance, lorsqu'un socket est établi, des threads sont créés pour surveiller ce socket jusqu'à la valeur "numAcceptThreads". Tout ce thread ne lit que les données du socket et le transmet à un thread dans le pool client (régi par maxPoolSize).

Les threads appelés workerThread # [] font référence aux threads acceptés. La raison pour laquelle je vois plus quand je crée plus de producteurs est parce que pour le transport de bisbocket pour Jboss Messaging il y a apparemment trois prises créées. Au départ il y en a 3, mais quand je crée 5 producteurs ce nombre est augmenté à 15 (ou 5 * 3 pour ceux qui ne sont pas mathématiquement enclins :)). La raison pour laquelle ils sont attribués à 100% est parce que quand j'envoie tous ces messages les threads lisent du socket, passons à Server Thread, retournons à la lecture du socket (où c'est toujours des données)

Ainsi le short réponse est il n'y a pas de pool pour régir ces discussions. Vous pouvez avoir plus d'un thread d'acceptation, mais cela n'aurait presque jamais de sens. Cela parce que son travail est si minime lire les données, le remettre, lire les données ... Donc, plus de threads ajouterait simplement la surcharge de synchronisation.

Source

2010-12-07 20:04:05 nsfyn55

-1

Ceci est de http://download.oracle.com/javase/tutorial/uiswing/concurrency/worker.html; J'espère que cela aide.

Lorsqu'un programme Swing doit exécuter une tâche de longue durée, il utilise généralement l'un des threads de travail, également appelés threads d'arrière-plan. Chaque tâche exécutée sur un thread de travail est représentée par une instance de javax.swing.SwingWorker. SwingWorker lui-même est une classe abstraite; vous devez définir une sous-classe pour créer un objet SwingWorker; Les classes internes anonymes sont souvent utiles pour créer des objets SwingWorker très simples.

Source

2010-12-07 19:09:29

C'est vraiment différent. Voir la réponse ci-dessous. – nsfyn55

Jboss Messaging WorkerThread # qu'est-ce que ces threads?

Répondre

Questions connexes