Red Hat Training
A Red Hat training course is available for Red Hat JBoss Enterprise Application Platform
Chapitre 9. Clustering dans les applications web
9.1. Réplique de session
9.1.1. La réplique de session HTTP
9.1.2. Cache de session web
standalone-ha.xml
, ou les profils de domaine gérés ha
ou full-ha
. Les éléments les plus couramment configurés sont le mode cache et le nombre de propriétaires de cache pour un cache distribué.
Le mode cache peut être REPL
(par défaut) ou DIST
.
- REPL
- Le mode
REPL
reproduit tout le cache à un nœud sur deux dans le cluster. Cela constitue l'option la plus sûre, mais elle introduit aussi plus de surcharge de temps. - DIST
- Le mode
DIST
est semblable au buddy mode fourni dans les exécutions précédentes. Il réduit la surcharge de temps en répartissant le cache entre le nombre de nœuds indiqués dans le paramètreowners
. Ce nombre de propriétaires est défini par défaut à2
.
Le paramètre owners
contrôle combien de nœuds de clusters détiennent des duplicata de la session. La valeur par défaut est 2
.
9.1.3. Configurer le cache de session web
REPL
. Si vous souhaitez utiliser le mode DIST
, exécutez les deux commandes suivantes dans l'interface CLI. Si vous utilisez un profil différent, changez le nom de profil dans les commandes. Si vous utilisez un serveur autonome, retirez la partie /profile=ha
des commandes.
Procédure 9.1. Configurer le cache de session web
Modifier le mode cache par défaut en
DIST
./profile=ha/subsystem=infinispan/cache-container=web/:write-attribute(name=default-cache,value=dist)
Définir le nombre de propriétaires de cache distribué.
La commande suivante définit5
propriétaires. La valeur par défaut est2
./profile=ha/subsystem=infinispan/cache-container=web/distributed-cache=dist/:write-attribute(name=owners,value=5)
Modifier le mode cache par défaut en
REPL
./profile=ha/subsystem=infinispan/cache-container=web/:write-attribute(name=default-cache,value=repl)
Relancer le serveur
Après avoir modifié le mode cache du web, vous devez relancer le serveur.
Votre serveur est configuré pour une copie de session. Pour utiliser une copie de session dans vos propres applications, veuillez vous référer au sujet suivant : Section 9.1.4, « Activer la copie de session pour votre application ».
9.1.4. Activer la copie de session pour votre application
Pour profiter des fonctionnalités HA (High Availability) de JBoss EAP 6, configurer votre application de manière à ce qu'elle soit distribuable. Cette procédure vous montrera comment y parvenir puis vous expliquera certaines options de configuration avancées que vous pourrez utiliser.
Procédure 9.2. Rendez votre Application Distribuable
Prérequis : indiquer que votre application est distribuable
Si votre application n'apparaît pas comme distribuable, ses sessions ne seront jamais distribuées. Ajouter l'élément<distributable/>
dans la balise<web-app>
du fichier descriptifweb.xml
de votre application. Voici un exemple :Exemple 9.1. Configuration minimum pour une application distribuable
<?xml version="1.0"?> <web-app xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd" version="2.4"> <distributable/> </web-app>
Modifier le comportement de réplication par défaut si vous le souhaitez.
Si vous souhaitez changer une des valeurs qui affectent la réplique de session, vous pouvez les changer dans l'élément<replication-config>
qui est un dépendant de l'élément enfant de l'élément<jboss-web>
du fichierjboss-web.xml
de votre application. Pour un exemple donné, ne l'inclure que si vous souhaitez remplacer les valeurs par défaut. L'exemple suivant énumère tous les paramètres par défaut, et est suivi d'un tableau qui explique les options les plus fréquemment modifées.Exemple 9.2. Valeurs
<replication-config>
par défaut<!DOCTYPE jboss-web PUBLIC "-//JBoss//DTD Web Application 5.0//EN" "http://www.jboss.org/j2ee/dtd/jboss-web_5_0.dtd"> <jboss-web> <replication-config> <cache-name>custom-session-cache</cache-name> <replication-trigger>SET</replication-trigger> <replication-granularity>ATTRIBUTE</replication-granularity> <use-jk>false</use-jk> <max-unreplicated-interval>30</max-unreplicated-interval> <snapshot-mode>INSTANT</snapshot-mode> <snapshot-interval>1000</snapshot-interval> <session-notification-policy>com.example.CustomSessionNotificationPolicy</session-notification-policy> </replication-config> </jboss-web>
Tableau 9.1. Options communes de réplication
Option
|
Description
|
---|---|
<replication-trigger>
|
Contrôle quelles conditions doivent déclencher la réplication de données de session dans l'ensemble du cluster. Cette option est utile, quand un objet mutable (stocké comme attribut de session) est accessible à partir de la session, le conteneur n'a aucun moyen évident de savoir si l'objet a été modifié et s'il doit être reproduit, sauf si la méthode
setAttribute() est appelée directement.
Valeurs valides pour
Quelle que soit la configuration, vous pourrez toujours déclencher la réplication de session en appelant
setAttribute() .
|
<replication-granularity>
|
Détermine la granularité des données répliquées. La valeur par défaut est
SESSION , mais peut être définie à ATTRIBUTE à la place, pour augmenter la performance dans les sessions où la plupart des attributs restent inchangés.
Valeurs valides de
Note FIELD n'est pas pris en charge dans JBoss EAP 6.
|
Tableau 9.2. Options les moins communément modifiées pour les réplications de session
Option
|
Description
|
---|---|
<use-jk>
|
Présumons qu'un équilibreur de charge tel que
mod_cluster , mod_jk , ou mod_proxy est utilisé. La valeur par défaut est false . Si définie comme true , le conteneur examine l'ID de session associé à chaque requête et remplace la partie jvmRoute de l'ID de session s'il y a un basculement.
|
<max-unreplicated-interval>
|
Le plus grand intervalle (en secondes) à attendre après qu'on ait pu accéder à une session avant de déclencher une réplication d'un horodateur de session, même s'il est considéré comme inchangé. Cela permet aux nœuds de cluster d'être informés de l'horodateur de chaque session et aux sessions non répliquées de ne pas expirer de manière incorrecte pendant un basculement. Cela vous permet également de vous fier à une valeur correcte pour les appels à méthode
HttpSession.getLastAccessedTime() pendant un basculement.
Par défaut, aucune valeur n'est indiquée. Une valeur
0 entraîne une réplication de l'horodateur à chaque accès à la session. Une valeur -1 n'entraîne une réplication de l'horodateur que si une autre activité entraîne une réplication pendant la requête. Une valeur positive supérieure à HttpSession.getMaxInactiveInterval() est traitée comme une erreur de configuration et sera convertie à 0 .
|
<snapshot-mode>
|
Indique quand les sessions sont répliquées vers d'autres nœuds. La valeur par défaut est
INSTANT et l'autre valeur possible est INTERVAL .
En mode
INSTANT , les modifications sont répliquées à la fin d'une requête, au moyen du thread de traitement des requêtes. L'option <snapshot-interval> est ignorée.
En mode
INTERVAL , une tâche d'arrière-plan s'exécute à l'intervalle indiqué par <snapshot-interval> , et réplique les sessions modifiées.
|
<snapshot-interval>
|
L'intervalle, en millisecondes, pendant lequel les sessions modifiées doivent être répliquées si elles utilisent
INTERVAL pour la valeur de <snapshot-mode> .
|
<session-notification-policy>
|
Nom complet de la classe de l'implémentation de l'interface
ClusteredSessionNotificationPolicy qui contrôle si les notifications de spécification servlet sont émises vers un HttpSessionListener , HttpSessionAttributeListener , ou HttpSessionBindingListener enregistré.
|