Nous avons rencontré un problème sous WebLogic 8.1 avec lequel nous vivions mais que nous ne pouvions jamais résoudre. Nous mettons souvent en file d'attente une centaine de messages JMS ou plus, chacun représentant une unité de travail. Malgré le fait que chaque message est de la même taille et se ressemble, on peut prendre seulement quelques secondes pour compléter, alors que le suivant représente 20 minutes de calcul solide. Notre problème est que chacun des beans pilotés par message que nous avons fait le travail de ces messages finit sur un fil qui semble saisir dix messages à la fois (nous pensons qu'il est fait comme une optimisation WebLogic à garder de avoir à frapper la file d'attente encore et encore pour les petits messages). Puis, comme un fil après l'autre finit tous ses petits travaux et aucun nouveau venu, nous nous retrouvons avec un journal de fil unique coincé sur une longue pièce de travail avec jusqu'à neuf autres objets assis en attente pour terminer, malgré le fait que d'autres threads sont gratuits et pourraient commencer sur ces unités de travail. Maintenant que nous sommes en train de convertir en WebLogic 10, il est naturel de revenir sur ce problème et de découvrir s'il existe une solution que nous pourrions implémenter pour que: un message JMS à la fois pour traiter et laisser tous les autres en attente dans la file d'attente entrante, ou b) il redistribuerait automatiquement les messages en attente (même ceux déjà assignés à un fil particulier) aux threads libres. Des idées?Les threads gourmands saisissent trop de messages JMS sous WebLogic
1
A
Répondre
1
Activer le délai de transfert et fournir une valeur appropriée. Cela entraînera la file d'attente JMS à redistribuer les messages à ses homologues s'ils n'ont pas été traités dans l'heure configurée. Prendre un seul message de la file d'attente à chaque fois peut être exagéré - Tout le monde est en équilibre sur le nombre de messages que vous traitez et sur ce que vous jugez être un problème.
Il existe également plusieurs problèmes avec JMS sur WebLogic 10 en fonction de votre configuration. Vous pouvez vous épargner beaucoup de temps et d'ennuis en utilisant le dernier MP dès le début.
0
lorsqu'un thread est « famine » après avoir obtenu les ressources dont ils peuvent pouvoir execute.The fils qui sont dans la famine appelé « fil gourmand »
Utilisez-vous la fonction de traitement par lots de transaction de WebLogic? – jarnbjo
Non. Au moins intentionnellement. La configuration est de permettre aux files d'attente d'accepter n'importe quel nombre de messages sans en écarter aucune et de les conserver sur le disque si nécessaire, mais au-delà, nous n'avons rien d'autre qui soit différent des valeurs par défaut. –
pourriez-vous fournir quelques détails sur l'implémentation du client JMS; si la session JMS est traitée (si non, quel mode d'accusé de réception est utilisé), est-ce que tous les consommateurs utilisent la même session, quand reconnaissez-vous la réception de message (le cas échéant), ... Un extrait de code de l'initialisation de communication aiderait beaucoup. –