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

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. add the coprocessor
hbase…

Analyse d'un "thread dump" d'une JVM IBM sous AIX

Dans quels cas le thread dump est utile ?
Le thread dump est un instantané de l'activité des threads de la JVM. Leur analyse est intéressante dans les cas où l'activité de la JVM ne semble pas normale :
Activité suspendue (deadlock/interblocage) ou partiellement suspendue (starvation/famine)Activité existante mais le "débit" est en deçà de ce qui est attendu (Goulot d'étranglement / Bottleneck)Activité existante mais le "débit" reste nul (Boucle infinie / Infinite Loop)Comment avoir un thread dump ?
Nous nous limitons ici à la machine virtuel IBM sous AIX. Dans ce cas là il est extrêmement simple de déclencher la création d'un thread dump : il suffit de faire un kill -3 sur le processus Java.

Un fichier dont le nom est javacore.[date].[numero_processus].[compteur].txt est produit. Sur la sortie standard du processus vous devriez voir la ligne suivante s'afficher :
JVMDUMP010I Java Dump written to .....
En général le dump est produit dans le réper…

Zookeeper, Netflix Curator and ACLs

If you have one or more Zookeeper "multi-tenant" clusters you may want to protect znodes against unwanted modifications.
Here is a very simple and short introduction to the ACL and custom authentication features.
This post is not intended to give you best practices about security and Zookeeper, the only goal is to give you a complete example of a custom authentication handler.
Complete source code with JUnit test is available here :
https://github.com/barkbay/zookeeper-acl-sample/ Use case Let say that your Zookeeper cluster is used by several users. In order to restrict user actions you have decided that each user must prefix all paths with the first letter of his name.
User foo is only allowed to create, read, delete and update znodes under the /f znode. User bar is only allowed to create, read, delete and update znodes under the /b znode.
Get client authentication data on the server side Zookeeper client authentication can be easily customized , all you have to do is to…