mercredi 7 décembre 2011

PRINCIPE


(Les versions étudiées sont Weblogic et Oracle DataBase 11G)

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.


JDBC STORE



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.

(Détail de la consommation du Pool avec les 2 connexions constamment en cours d’utilisation)

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.

consoleà${domaine}àServicesàData Sourcesà${DataSource Name}àConfigurationàConnection PoolàAdvanced
àStatement Timeout : 5

  
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.


Dans le cas d’indisponibilité totale de la base ou du RAC (tous les nœuds tombés). Une solution proposée par le support Oracle est d’activer la migration de ressource (Whole Server Migration) qui en cas de panne de ce type cherche à faire un rejeux sur le Store et le réactive sans basculer (à confirmer avec le support). Il n’est donc plus nécessaire de redémarrer l’instance. Il faudra valider cette partie avec un test de robustesse.


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.

-Dweblogic.store.jdbc.IORetryDelaySeconds=[1-15]


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

consoleà${domaine}àServicesàData Sourcesà${DataSource Name}àConfigurationàConnection PoolàAdvanced
àSeconds to Trust an Idle Pool Connection : 0
àTest Connections On Reserve : true

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)

consoleà${domaine}àServicesàData Sourcesà${DataSource Name}àConfigurationàConnection PoolàAdvanced
à Connection Creation Retry Frequency: 600

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

oracle.ddl
# WebLogic JDBC Store DDL for Oracle
# Copyright (c) 2003 by BEA, Inc., All Rights Reserved

CREATE TABLE $TABLE (
  id     int  not null primary key,
  type   int  not null,
  handle int  not null,
  record long raw not null
);

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

${PREFIXE_NAME}WLSTORE

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



JDBCSTORE1WLSTORE

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.


FILE STORE


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 :

${DOMAIN_NAME}\servers\${INSTANCE_NAME}\data\store\default\_WLS_${INSTANCE_NAME}000000.DAT

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

${FILESTORE_HOME}\${FILESTORE_NAME}######.DAT

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.

STORE


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

ü  Dans le code client.
ü  Dans l’objet Factory de connection (${factory}àConfigurationàDefault DeliveryàDefault Delivery Mode : Persistent)
ü  Dans les Queues/Topic (${factory}àConfigurationàOverrideàDefault Delivery Mode : Persistent)

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

FILE VS JDBC


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


FILE
JDBC
Sécurisation

X
Performant
X

Tolérance aux pannes
X

Reprise Sur Erreur

X

1 commentaires:

Tony Rieublanc a dit…
Ce commentaire a été supprimé par l'auteur.

AUTEUR

Ma photo
Carrières Sur Sein, Yvelines, France
Consultant Oracle (Ancien consultant BEA depuis 2001), je m’occupe des expertises sur les produits Oracle : SOCLE (Weblogic, Coherence, JRockit) SOA (Service Bus, SOA Suite, BPM)
MON CV

LABEL 3D

Blogumulus by Roy Tanck and Amanda Fazani

LABEL CLOUD

MAP

Locations of visitors to this page

AUTRES BLOG

LIVRES

MEMBRES