Ou « Combien de messages JMS un serveur JMS peut-t-il emmagasiner ? » Sous Weblogic (je ne sais pas comment cela se passe avec les autres) tout message JMS est stocké au moins partiellement dans la mémoire de la JVM, et cette mémoire n'étant pas infinie l'arrivée d'un grand nombre de messages associée à une mauvaise configuration du sous système JMS se solde souvent par un OutOfMemory.
Le schéma ci dessous montrent les différents mécanismes qui peuvent être mis œuvre par un serveur JMS afin de gérer l'accumulation des messages JMS et de réguler leur arrivée.
1. Définir un quota
Un message JMS consomme toujours de la mémoire. Partant de ce postulat un quota devrait toujours être défini sur un serveur JMS. Il évitera une saturation mémoire en refusant aux producteurs de poster des nouveaux messages lorsque le quota est atteint.
Les quotas peuvent être définis au niveau des modules JMS, cependant il peut être plus "sécurisant" de les placer directement au niveau du serveur JMS :
Les quotas peuvent être définis au niveau des modules JMS, cependant il peut être plus "sécurisant" de les placer directement au niveau du serveur JMS :
JMS Servers - Configuration - Thresholds and Quotas |
Que se passe-t-il du coté des producteurs lorsqu'un quota est atteint ?
La « connection factory » peut spécifier un « Send Timeout ». Cela permet de mettre en attente un client un certain temps lorsque le quota est atteint. A l'issue de ce temps d'attente deux cas sont possibles :
- Suffisamment d'espace a été libéré pour accepter le message sans repasser au dessus du quota : le producteur peut au final poster son message.
- Le quota est toujours atteint : une exception de type "ressource allocation" est levée
Notez que par défaut si un message volumineux arrive et que sa taille entraîne un dépassement du quota il bloquera des messages plus petits qui pourraient être délivrés sans le dépasser. Si l'ordre des messages n'est pas une nécessité vous pouvez permettre aux petits messages de passer devant les plus gros : toujours dans la section "quotas", choisissez Preemptive à la place de FIFO dans le champ Blocking Send Policy.
2. Paging
Le « Paging » consiste à ne conserver en mémoire que l'entête des messages JMS. Le corps est sérialisé dans un répertoire appelé Paging Directory. Par défaut les serveurs JMS sont tous capables de faire du paging et ils le font lorsque la mémoire occupée atteint 1/3 du Heap ou 512Mo. Le champ Message Buffer Size vous permet de personnaliser cette valeur.
JMS Servers - Configuration |
Il faut toujours garder à l'esprit que le paging ne suffit pas à prévenir une saturation mémoire, les entêtes des messages JMS étant toujours gardées en mémoire.
Comme on peut le voir dans l'extrait ci dessus de la mémoire d'un serveur Weblogic, les messages JMS de type TextMessage qui occupent ici presque 8Ko sont remplacés au fur et à mesure de leur arrivée par une simple référence qui n'occupe plus que 200 octets.
Attention à ceux qui utilisent les "JMS Message Selector" pour trouver des messages particuliers dans une destination, seuls les entêtes "systèmes", propres à Weblogic, sont conservés en mémoire. Une requête basée sur d'autres entêtes et effectuée sur un message "paginé" sera plus lente que si le message était en mémoire.
Attention à ceux qui utilisent les "JMS Message Selector" pour trouver des messages particuliers dans une destination, seuls les entêtes "systèmes", propres à Weblogic, sont conservés en mémoire. Une requête basée sur d'autres entêtes et effectuée sur un message "paginé" sera plus lente que si le message était en mémoire.
3. Contrôle de débit (Flow Control)
Le contrôle de débit permet de ralentir la production de message lorsqu'un seuil (Threshold) est atteint, on dit alors d'un serveur JMS ou d'une destination qu'il devient « armé ». Ce seuil peut être aussi bien exprimé en terme de nombres de messages ou d'octets occupés par les messages.
Configuration du contrôle de débit
La configuration du Flow Control se fait dans la configuration de la Connection Factory. Les 2 paramètres intéressants sont :
- Flow Maximum : le nombre maximum de messages par seconde qui peuvent être posté par un producteur dans une condition de seuil.
- Flow Minimum :le débit minimal qui pourra être demandé par le serveur JMS à un producteur.
JMS Modules - Connection factory - Configuration - Flow Control
Contrôle des seuils
2 seuils sont exprimés dans la configuration d'un serveur JMS
- Le seuil haut : c'est le niveau à partir duquel le serveur JMS est « armé »
- Le seuil bas : c'est le niveau en dessous duquel les producteurs peuvent augmenter le débit d'envoi des messages.
Configuration du serveur JMS : définition des seuils (threshold) |
Lorsqu'un seuil est dépassé l'état de santé du serveur qui héberge le serveur Weblogic passe de "Ok" à "Warning"
Si vous avez mis en place une supervision basée sur l'interrogation des MBeans du serveurs vous serez donc averti de l'incident.
Le message suivant devrait aussi s'afficher dans les logs du serveur lorsqu'une condition de seuil est atteinte :
BEA-040030 JMSServer "JMSServer-0" message threshold for the server has been exceeded.
BEA-040028 JMSServer "JMSServer-0" byte threshold for the server has been exceeded
Le message suivant devrait aussi s'afficher dans les logs du serveur lorsqu'une condition de seuil est atteinte :
Comments
Post a Comment