Skip to main content

Configuration avancée d'un serveur JMS sous Oracle Weblogic

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 :
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.

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

Comments

Popular posts from this blog

Orientée colonnes ?

Les bases NoSQL sont arrivées avec leur cortège de nouveautés et pour certaines d'entre elles une notion héritée de BigTable : celle de base de donnée orientée colonne. Cependant faire le lien entre l'article de Wikipedia et comprendre ce que permet réellement un base de donnée comme HBase n'est pas une chose évidente. En effet le simple fait de définir cette notion ne suffit pas toujours a bien comprendre quels sont les principes de conception du monde SQL qui peuvent être oubliés et ceux qui doivent être appris. Colonne or not colonne ? Prenons un modèle très simple de donnée et essayons de le transposer dans un modèle "orienté colonne": Comme on peut le voir on est passé d'un modèle à 2 dimensions (ligne x colonne) vers un modèle où une valeur est accédée au travers de 2  coordonnées qui sont ici (ligne, colonne) Cette notion de coordonnées est  importante  (c'est pour ça que je la met en gras 2 fois de suite) si l'on veut c

Row Count : HBase Aggregation example

With the coprocessors HBase 0.92 introduces a new way to process data directly on a region server. As a user this is definitively a very exciting feature : now you can easily define your own distributed data services. This post is not intended to help you how to define them (i highly recommend you to watch this presentation if you want to do so) but to quickly presents the new aggregation service shipped with HBase 0.92 that is built upon the endpoint coprocessor framework. 1. Enable AggregationClient coprocessor You have two choices : You can enable aggregation coprocessor on all your tables by adding the following lines to hbase-site.xml : <property> <name>hbase.coprocessor.user.region.classes</name> <value>org.apache.hadoop.hbase.coprocessor.AggregateImplementation</value> </property> or ...you can enable coprocessor only on a table throught the HBase shell : 1. disable the table hbase> disable ' mytable ' 2.

HBase + Subversion + Eclipse + Windows

HBase + Subversion + Eclipse + Windows (it should be easy to adapt for Linux) Update : please note that since HBase-4336 / HBase 0.96 the source tree is split in more than one Maven module this post is no more relevant, i have created a new post on this subject : http://michaelmorello.blogspot.fr/2012/06/hbase-096-eclipse-maven.html This is a simple setup in order to play with the source code of HBase under Microsoft Windows. Since HBase use some Unix specific commands like chmod the only requirements here are  Cygwin and a working Maven 3 environment. (It is obvious that you need Java and Eclipse , but you DON'T need anything else like the Eclipse Maven plugin or any SSH configuration) 1. Checkout the source code The first step is to check out the source code from the Subversion repository. I did it under my cygwin home repository. In this example i want to play with the 0.90 branch : svn co http://svn.apache.org/repos/asf/hbase/branches/0.90/ hbase-0.90