Jean FRANCOIS blog [Weblogic / Java EE / SOA]

---

Lors de l’utilisation d’une file JMS, les messages sont persistés dans une zone de sauvegarde appelée Store qui permet de conserver et reprendre les données lors de panne d’instance. Le message est sauvegardé lors de la mise en file, puis supprimé lors de sa consommation.

Nous avons deux types possibles :

ü  FileStore     Persistance en fichier.

ü  JDBCStore     Persistance en base.

---

Le JDBC Store nécessite la création d’un DataSource associé à la base qui va héberger les messages. Le DataSource à créer doit être non XA car c’est l’implémentation JMS Weblogic qui supporte l’aspect transactionnel (de toutes les façons, l’IHM de création d’un JDBCStore ne fait apparaître que les DataSource non XA).

Il faudra donc créer un DataSource spécifique pour le JDBCStore non partagé par les applications déployées. Prendre un driver non XA et décocher l’option Supports Global Transactions.

Le JDBCStore n’utilise qu’au maximum 3 connexions et en conserver 2 (connexion qu’il ne relâche jamais et ne remet donc pas dans le pool). Il faudra donc prévoir une taille de pool avec la considération de 3 connexions par JDBCStore.

Comme la connexion est maintenue par la ressource du Store, on pourra mettre un timeout sur la connexion avec le paramètre Statement Timeout afin de libérer celle-ci en cas de non-réponse de la base. Cela s’avère nécessaire lors de l’utilisation du MultiDataSource avec la perte d’un nœud RAC associé à la tombée d’une machine. Dans ce cas de figure, les threads associés à la gestion JMS sont bloqués sur l’accès base en non-réponse.

  

Dans le cas d’un MutliDataSource, ne pas mettre de load balancing, mais plutôt le failover. Dans le cas de forte volumétrie, dissocier les DataBase et multiplier les serveurs JMS et JDBC Store.

Un problème intervient sur les JDBC Store lorsque la base tombe u. Dans ce cas de figure, le DataSource passe en status Failed v et si un message passe sur la file, le Store se met en échec w. Lors de la remontée de la base x, le DataSource se remet automatiquement y, mais pas le Store z. Il faut dans ce cas remonter l’instance Weblogic.

Pour les indisponibilités passagères (problème réseau, etc ), lorsque la connexion du DataSource devient inaccessible, un mécanisme de retry de connexion du JDBCStore est mis en jeux. Par défaut, l’attente avant le retry est de 1s. On pourra modifier cette valeur avec un maximum de 15s avec le properties JAVA suivant. On pourra donc positionner cette valeur à 10.

Concernant les DataSource, il est préférable de les paramétrer avec un test systématique et un Trust de connexion à 0 (temps de durée de validation d’une connexion testé) afin d’être sur que la connexion utilisée est valide (sans échec possible de requêtage).

Si la base n’est pas en RAC, vous pouvez mettre un Connection Creation Retry Frequency à 600 afin de se reconnecter ultérieurement (attention recommandation de la documentation Oracle mais impliquant une accumulation de transaction avec un dépassement de capacité mémoire ou autre dysfonctionnement possible)

Le JDBCStore utilise une table qu’il crée au démarrage de l’instance via des scriptes DDL contenu dans  MW_HOME\modules\com.bea.core.store.jdbc_1.0.0.0.jar. On peut les créer manuellement comme le présente l’exemple suivant (en remplaçant le $TABLE par le nom de la table) :

Concernant le nom de la table la convention est la suivante :

Le Prefixe Name permet de n’avoir qu’une seule table distincte par Store.

Lorsque la base n’est plus disponible et que le Store passe en Failed, Les messages passent d’un status visible en send transaction. Il faut dans ce cas de figure, exporter les messages en mémoire dans un fichier puis les re importer après redémarrage de la base et de l’instance WLS.

---

Par défaut, Weblogic déclare un File Store même si l’on n’a pas déclaré de Store pour le serveur JMS (Store utilisé pour les transactions log JTA ainsi que les messages JMS). Ce Store par défaut se trouve dans le répertoire :

Lorsque l’on déclare un FileStore, on peut le spécifier dans un répertoire global à toutes les instances de préférence partagée par toutes les machines de façon à effectuer des reprises en cas de panne machine. Chaque instance devant utiliser un FileStore différent sous peine d’avoir des incohérences dans la diffusion des messages (il vaut mieux créer le répertoire au par avance avant de créer la ressource).

Le nom fichier du FileStore aura la convention suivante ou #### représente un nombre unique de différentiations (dans le cas de nom identique).

Le File Store définit 3 types de politiques d’écriture qui peut être conservée avec le mode par défaut qui est le Direct-Write (utilisant une librairie native I/O wlfileio2 ).

Pour le répertoire partagé, préférer un disque SAN plutôt que NFS qui n’a pas forcement de support pour les écritures directes et qui peuvent entraîner des lock d’écritures. Si vous avez la possibilité,  essayer de placer les fichiers sur des disques dédiés (voir plateaux) pour de la forte volumétrie afin de dissocier les accès disque.

La taille des fichiers issue du FileStore est gérée par le Store lui-même qui peut s’agrandir selon les besoins, mais jamais diminuer. Prévoir donc un FileSystem conséquent par rapport à votre charge.

---

L’action de persistance (File ou Base) est un paramétrage qui peut se définir à plusieurs niveaux.

ü  Dans le code client.

La durée de rétention est différente selon les cas. Dans le cas des Topic, le message est persisté jusqu’a ce que tous les souscripteurs ont consommé le message. Dans le cas des Queues, le message est retiré du Store une fois consommé. Dans tous les cas, le message est retiré en cas d’expiration ou suppression administrative.

Chose importante pour la volumétrie mémoire, les Header JMS sons conservés en mémoire, ainsi qu’un certain nombre de messages même s’ils sont persisté dans le Store (pour des considérations de performance).

---

Le choix entre les deux types de Store peut se résumer à un besoin de performance ou de fiabilité et de souplesse de reprise sur erreur.

Le mode File est plus performant et plus tolérant par rapport à une indisponibilité de base (à condition d’avoir un File System performant sans perte au niveau des caches en écriture). Il a le désavantage de devoir mettre en place un File System partagée pour les reprises en cas de panne machine. On le choisira pour de fortes volumétries et des contraintes de temps de réponse.

Le mode JDBC à l’avantage d’avoir un mode centralisé natif (via la database) et facilite les reprises en cas de panne machine, mais avec des temps moins performants par rapport au mode File. Il supporte difficilement les pertes momentanées des bases avec comme contrainte de devoir redémarrer les instances. On le choisira pour des besoins de sécurisation sans avoir de contrainte de temps de réponse (de préférence à utiliser avec une base clustérisée pour éviter les indisponibilités et redémarrage intempestif).