I. Avertissement▲
Vous êtes libres :
• de reproduire, distribuer et communiquer cette création au public.
Paternité .
Vous devez citer le nom de l'auteur original de la manière indiquée par l'auteur de l'œuvre ou le titulaire des droits qui vous confère cette autorisation (mais pas d'une manière qui suggérerait qu'ils vous soutiennent ou approuvent votre utilisation de l'œuvre).
Pas d'Utilisation Commerciale .
Vous n'avez pas le droit d'utiliser cette création à des fins commerciales.
Pas de Modification .
Vous n'avez pas le droit de modifier, de transformer ou d'adapter cette création.
À chaque réutilisation ou distribution de cette création, vous devez faire apparaître clairement au public les conditions contractuelles de sa mise à disposition.
• Chacune de ces conditions peut être levée si vous obtenez l'autorisation du titulaire des droits.
• Rien dans ce contrat ne diminue ou ne restreint le droit moral de l'auteur ou des auteurs.
Ceci est le Résumé Explicatif du Code Juridique. La version intégrale du contrat est attachée en fin de document et disponible sur :
http://creativecommons.org/licenses/by-nc-nd/2.0/fr/legalcode
II. Vue d'ensemble▲
Dans les entreprises, il est fréquent de trouver des traitements qu'il serait possible de classer dans la catégorie des traitements interactifs (TI) et d'autres dans celle des traitements par lots (TL). La plupart du temps, ces traitements, bien qu'ayant des comportements très différents, partagent les mêmes ressources. Parfois, cependant, il devient critique de dédier des ressources à chacune de ces catégories, car les traitements de l'une perturbent le déroulement des traitements de l'autre. Pourtant, il est difficile de prendre la décision d'investir dans des machines qui ne seront pas utilisées pendant certaines périodes de la journée. C'est souvent le cas pour les traitements interactifs dont les utilisateurs se trouvent dans la même zone géographique, et dont, la nuit, une partie des ressources pourrait être affectée aux traitements par lots.
Dans cet article, nous allons voir comment gérer l'affectation dynamique de ressources lorsque le système d'information est bâti sur l'utilisation de serveurs d'applications JBoss AS.
III. Traitements interactifs▲
Dans notre exemple, nous simulons un système de traitements interactifs par la mise en place d'un cluster de serveurs JBoss AS, chacun hébergeant un EJB session stateless. Une application Java simple fait des appels à ce cluster en invoquant la seule méthode définie au niveau de l'EJB.
III-A. Installation du Cluster▲
Si vous avez à votre disposition l'exemple fourni avec cet article, les trois serveurs JBoss AS sont déjà installés dans le répertoire jboss . Pour ceux qui voudraient avoir le détail de l'installation, la suite en fait la description.
L'installation d'un cluster de deux serveurs JBoss AS sur votre machine est assez simple à réaliser. Il vous faut récupérer une distribution de JBoss AS disponible en téléchargement à l'adresse http://www.jboss.com/products/jbossas/downloads .
L'installation ne consiste qu'à décompresser l'archive .zip ou .tgz dans le répertoire de votre choix que nous nommerons pour plus de simplicité JBOSS_HOME . Vous devriez y trouver les sous-répertoires bin , client , docs , lib et server .
C'est dans ce dernier qu'il vous faut trouver le sous-répertoire all contenant la configuration d'un serveur JBoss AS dont les services de cluster sont activés. Faites-en deux copies, une nommée nœud_ti pour « nœud traitements interactifs » et l'autre nœud_ti_tl parce que c'est celui qui est destiné à basculer des traitements interactifs aux traitements par lots et vice-versa.
Vous disposez désormais des deux serveurs JBoss AS en cluster, mais vous ne pouvez pas les lancer sur la même machine sous peine d'avoir des conflits d'accès aux différents ports TCP/IP utilisés. Pour configurer ces ports de manière centralisée, il vous faut utiliser le service nommé « Binding Manager » qui permet de configurer les ports utilisés par des serveurs JBoss AS au sein d'un seul fichier XML. Heureusement, la distribution que nous venons de télécharger dispose d'un tel fichier prêt à l'emploi. Il se trouve dans le répertoire JBOSS_HOME/docs/examples/binding-manager et se nomme sample-bindings.xml . Faites-en une copie que vous placerez dans le répertoire JBOSS_HOME/server .
Par chance, le fichier principal de configuration d'un serveur JBoss AS est déjà configuré pour utiliser ce fichier d'exemple. Il ne nous reste qu'à activer le service et définir le nom logique attaché à un ensemble de ports TCP/IP à utiliser pour chacun de nos deux nœuds.
Dans le fichier JBOSS_HOME/server/nœud_ti/conf/jbossservice. xml , activez le service en déplaçant les lignes correspondantes hors du commentaire et c'est tout :
<!--
|
Binding service manager for
port/
host mapping. This is a sample
|
config that demonstrates a JBoss instances with
a server name &
#8216
;ports-
01
'
|
loading its bindings from an XML file using the ServicesStoreFactory
|
implementation returned by the XMLServicesStoreFactory.
|
...
-->
<
mbean code=&
#8221
;org.jboss.services.binding.ServiceBindingManager&
#8221
;
name=&
#8221
;jboss.system:service=
ServiceBindingManager&
#8221
;>
<
attribute name=&
#8221
;ServerName&
#8221
;>
ports-
01
</
attribute>
<
attribute name=&
#8221
;StoreURL&
#8221
;>
../
server/
sample-
bindings.xml</
attribute>
<
attribute name=&
#8221
;StoreFactoryClassName&
#8221
;>
org.jboss.services.binding.XMLServicesStoreFactory
</
attribute>
</
mbean>
Dans le fichier de configuration du deuxième nœud, JBOSS_ HOME/server/nœud_ti_tl/conf/jboss-service.xml , activez le service de la même manière, mais remplacez la valeur ports-01 par ports-02 .
port-01 et port-02 sont des valeurs utilisées dans le fichier sample-binding.xml pour désigner un ensemble
de valeurs pour les ports TCP/IP du serveur JBoss AS.
Et voilà ! Vous pouvez lancer vos deux serveurs JBoss AS.
Placez-vous dans le répertoire JBOSS_HOME/bin et lancez les commandes run.bat -c nœud_ti et run.bat -c nœud_ti_tl (ou run.sh sous Linux).
III-B. L'EJB Session Stateless▲
Cet EJB n'expose qu'une méthode, String getHostname(int in_count) , qui retourne le nom du serveur qui traite la requête du client. Cette méthode simule un traitement assez long (boucle de 10 fois sleep(2000); ) afin de faciliter la visualisation de ce qui se passe.
16:21:48,748 INFO [STDOUT] localhost[noeud_ti_tl]-1 loop : 0
16:21:50,752 INFO [STDOUT] localhost[noeud_ti_tl]-1 loop : 1
16:21:52,756 INFO [STDOUT] localhost[noeud_ti_tl]-1 loop : 2
16:21:54,760 INFO [STDOUT] localhost[noeud_ti_tl]-1 loop : 3
16:21:56,764 INFO [STDOUT] localhost[noeud_ti_tl]-1 loop : 4
16:21:58,769 INFO [STDOUT] localhost[noeud_ti_tl]-1 loop : 5
16:22:00,773 INFO [STDOUT] localhost[noeud_ti_tl]-1 loop : 6
16:22:02,777 INFO [STDOUT] localhost[noeud_ti_tl]-1 loop : 7
16:22:04,781 INFO [STDOUT] localhost[noeud_ti_tl]-1 loop : 8
16:22:06,785 INFO [STDOUT] localhost[noeud_ti_tl]-1 loop : 9
16:22:28,846 INFO [STDOUT] localhost[noeud_ti_tl]-3 loop : 0
16:22:30,850 INFO [STDOUT] localhost[noeud_ti_tl]-3 loop : 1
16:22:32,854 INFO [STDOUT] localhost[noeud_ti_tl]-3 loop : 2
III-C. Le Client▲
Le client est écrit pour être utilisé à la fois comme un client de traitements interactifs et comme client de traitements par lots. Pour simuler le traitement interactif, le client fait des appels vers l'EJB session stateless déployé dans le cluster.
run-
ejb:
[java] Demarrage : 0
[java] [Thread-
0
] : localhost[noeud_ti]-
0
[java] [Thread-
0
] : localhost[noeud_ti_tl]-
1
[java] [Thread-
0
] : localhost[noeud_ti]-
2
[java] [Thread-
0
] : localhost[noeud_ti_tl]-
3
[java] [Thread-
0
] : localhost[noeud_ti]-
4
IV. Traitements par Lots▲
Notre système de traitements par lots repose sur l'utilisation d'un cluster de serveurs JBoss MQ et de production de messages JMS décrivant le traitement à exécuter par un ensemble de pools d'EJB MDB.
Cette configuration permet à loisir d'ajouter des pools de MDB pour augmenter la puissance de traitement. Notre but n'étant que de montrer comment faire basculer une ressource d'une nature de traitements vers l'autre, nous simplifions notre exemple et ne configurerons qu'un simple serveur JMS.
Dans le même serveur JBoss AS, nous configurons un pool de MDB qui pointe vers la queue queue/MessageQueue définie dans ce serveur JBoss MQ.
IV-A. Installation du serveur▲
De la distribution téléchargée précédemment, nous allons utiliser la configuration par défaut JBOSS_HOME/server/default . Copiez ce répertoire et renommez le nœud_tl . Il nous faut y configurer la queue queue/MessageQueue . Ceux qui disposent de l'exemple fourni avec cet article n'auront qu'à suivre les instructions décrivant le fonctionnement de l'exemple ci-après. Pour les autres, il faut copier un fichier ma-destination-service.xml (par exemple) dans le répertoire JBOSS_HOME/server/default/ deploy/jms décrivant la destination :
<
?xml version=
»1.0
» encoding=
»UTF-
8
»?>
<
server>
<
mbean code=
»org.jboss.mq.server.jmx.Queue»
name=
»jboss.mq.destination:service=
Queue,name=
MessageQueue»>
<
attribute name=
»JNDIName»>
queue/
MessageQueue</
attribute>
<
attribute name=
»ReceiversImpl»>
org.jboss.mq.server.ReceiversImplArrayList</
attribute>
<
depends optional-
attribute-
name=&
#8221
;DestinationManager&
#8221
;>
jboss.mq:service=
DestinationManager</
depends>
</
mbean>
</
server>
V. L'EJB MDB▲
Là encore, la méthode onMessage(…) simule un traitement long permettant de mettre en évidence le fonctionnement du basculement. Chaque MDB fera 10 boucles. Ci-dessous, le MDB utilisant le thread Worker 0 a fait trois tours de boucle.
16:07:24,286 INFO [STDOUT] [Thread: JMS SessionPool Worker-0] Working .... i == 0
16:07:25,256 INFO [STDOUT] [Thread: JMS SessionPool Worker-1] Working .... i == 0
16:07:26,264 INFO [STDOUT] [Thread: JMS SessionPool Worker-2] Working .... i == 0
16:07:26,295 INFO [STDOUT] [Thread: JMS SessionPool Worker-0] Working .... i == 1
16:07:27,259 INFO [STDOUT] [Thread: JMS SessionPool Worker-1] Working .... i == 1
16:07:27,267 INFO [STDOUT] [Thread: JMS SessionPool Worker-3] Working .... i == 0
16:07:28,267 INFO [STDOUT] [Thread: JMS SessionPool Worker-2] Working .... i == 1
16:07:28,272 INFO [STDOUT] [Thread: JMS SessionPool Worker-4] Working .... i == 0
16:07:28,300 INFO [STDOUT] [Thread: JMS SessionPool Worker-0] Working .... i == 2
16:07:29,263 INFO [STDOUT] [Thread: JMS SessionPool Worker-1] Working .... i == 2
16:07:29,271 INFO [STDOUT] [Thread: JMS SessionPool Worker-3] Working .... i == 1
V-A. Le Client▲
Le client est un client JMS classique qui produit des messages dans la queue queue/MessageQueue .
run-
ejb:
[java] Demarrage : 0
[java] ClientEjb.jmsConnect
(
)
[java] ClientEjb.jmsConnect : connected==
true
[java] Sending : 0
: MSG-
00001
-
16
-
23
-
43
-
010
[java] Sending : 0
: MSG-
00002
-
16
-
23
-
44
-
018
[java] Sending : 0
: MSG-
00003
-
16
-
23
-
45
-
022
V-B. Configuration de la connexion des MDB du nœud_ti_tl▲
Maintenant, il nous faut configurer le JMSProvider des MDB du nœud_ti_tl pour qu'ils se connectent au serveur JMS de notre serveur nœud_tl .
Pour les besoins de cet article, nous prenons un raccourci
Pour les besoins de cet article, nous prenons un raccourci en configurant le JMSProvider par défaut. Il est conseillé de se reporter à la documentation de JBoss AS pour réaliser cette opération d'une manière plus appropriée (i. e. : créer une configuration de conteneur MDB pointant sur le JMSProvider que vous aurez défini. Puis, configurer votre MDB pour qu'il utilise cette configuration).
Dans le fichier JBOSS_HOME/server/nœud_ ti_tp/deploy/jms/hajndi-jms-ds.xml , il faut changer le port 1100 par 1099 , car notre serveur est bien sûr localhost , mais il n'est pas démarré en cluster :
<!--
The JMS provider loader -->
<
mbean code=
»org.jboss.jms.jndi.JMSProviderLoader»
name=
»jboss.mq:service=
JMSProviderLoader,name=
HAJNDIJMSProvider»>
<
attribute name=
»ProviderName»>
DefaultJMSProvider</
attribute>
<
attribute name=
»ProviderAdapterClass»>
org.jboss.jms.jndi.JNDIProviderAdapter
</
attribute>
<!--
The queue connection factory -->
<
attribute name=
»QueueFactoryRef»>
XAConnectionFactory</
attribute>
<!--
The topic factory &
#8594
;
<
attribute name=
»TopicFactoryRef»>
XAConnectionFactory</
attribute>
<!--
Access JMS via HAJNDI -->
<
attribute name=
»Properties»>
java.naming.factory.initial=
org.jnp.interfaces.NamingContextFactory
java.naming.factory.url.pkgs=
org.jboss.naming:org.jnp.interfaces
java.naming.provider.url=
localhost:1099
</
attribute>
</
mbean>
Cette partie de la configuration est sujette aux remplacements des ports TCP/IP du Binding Manager. Pour éviter l'écrasement des valeurs ci-dessus, modifiez le fichier BOSS_HOME/server/samplebinding. xml pour mettre en commentaire la partie concernant le fichier hajndi-jms-ds.xml pour la configuration port-02 .
<!--
**********************************************************
-->
<!--
*
ports-
02
*
-->
<!--
**********************************************************
-->
<
server name=&
#8221
;ports-
02
&
#8221
;>
...
<!--
*********************
hajndi-
jms-
ds.xml ****************
-->
<!--
The JMS provider loader
<
service-
config name=&
#8221
;jboss.mq:service=
JMSProviderLoader,name=
HAJNDIJMSProvider&
#8221
;
delegateClass=&
#8221
;org.jboss.services.binding.AttributeMappingDelegate&
#8221
;>-->
<!--
!===============================!
ON NE VEUT PAS DE CETTE MODIF
POUR LE NOEUD_TI_TL
!===============================!
MAKE SURE java.naming.provider.url
PORT IS SAME AS HA-
JNDI ABOVE !!!
<
delegate-
config>
<
attribute name=
»Properties»><!
[CDATA[
java.naming.factory.initial=
org.jnp.interfaces.NamingContextFactory
java.naming.factory.url.pkgs=
org.jboss.naming:org.jnp.interfaces
java.naming.provider.url=
${
jboss.bind.address:localhost}
:1300
jnp.disableDiscovery=
false
jnp.partitionName=
${
jboss.partition.name:DefaultPartition}
jnp.discoveryGroup=
${
jboss.partition.udpGroup:230.0.0.4
}
jnp.discoveryPort=
1102
jnp.discoveryTTL=
16
jnp.discoveryTimeout=
5000
jnp.maxRetries=
1
]]>
</
attribute>
</
delegate-
config>
-->
<!--
NOTE: YOU MUST ADD THIS ELEMENT, BUT THE VALUE DOESN'T MATTER
BE SURE THE CORRECT VALUE IS IN java.naming.provider.url ABOVE
<
binding port=&
#8221
;1300
&
#8221
;/>
</
service-
config>-->
...
</
server>
V-C. Démarrage du nœud_ti_tl sans activer ses MDB▲
Pour que le pool de MDB de nœud_ti_tl ne reçoive pas les messages de la queue au démarrage, il faut soit le configurer dans son fichier jboss.xml , soit le configurer dans le fichier JBOSS_HOME/server/nœud_ti_tl/conf/jbossstandard.xml :
&
#8230
;
<
MDBConfig>
<!--
DESACTIVATION DES MDBs par defaut -->
<
DeliveryActive>
false
</
DeliveryActive>
<
ReconnectIntervalSec>
10
</
ReconnectIntervalSec>
&
#8230
;
VI. Le basculement d'un nœud▲
Il ne reste plus qu'à lancer les trois serveurs ainsi que les deux clients.
VI-A. Étape 1 : arrêt de la partition▲
L'arrêt de la partition sur le nœud_ti_tl permet de rendre invisible l'EJB session stateless y étant déployé aux yeux du client. Les traitements interactifs en cours sur le nœud_ti_tl par l'EJB se termineront normalement. Mais aucune nouvelle requête ne lui sera adressée.
L'arrêt d'une partition se fait via une commande JMX qu'il est possible de lancer à partir de la console JMX ou à l'aide de l'utilitaire twiddle disponible dans le répertoire JBOSS_HOME/ bin . Le serveur nœud_ti_tl étant associé à la liste de ports TCP/IP ports-2 , la commande à utiliser est la suivante :
twiddle -s localhost:1299 invoke «jboss:service=DefaultPartition» stop
VI-B. Étape 2 : activation de la réception des messages▲
Là encore, une commande JMX permet de réactiver la réception des messages par le pool de MDB sur le nœud_ti_tl .
twiddle -s localhost:1299 invoke «jboss.j2ee:binding=message-drivenbean,
jndiName=MessageEjb,plugin=invoker,service=EJB» stopDelivery
VI-C. Étape 3 : retour à l'état initial▲
À l'inverse, pour rebasculer, il faut arrêter la réception des messages, puis redémarrer la partition. L'arrêt de la réception des messages ne rendra la main que lorsque le traitement du dernier message en cours se termine.
VII. Utilisation de l'exemple▲
VII-A. Prérequis▲
Vous devez disposer d'un JDK (1.4 ou 5) et Ant doit être installé.
VII-B. Vue d'ensemble▲
Une fois l'extraction de l'archive effectuée, vous obtenez l'arborescence ci-dessus. On y reconnaît un ensemble de fichiers de commande ( .bat pour Windows et .sh pour Linux). Dans les répertoires se trouvent les sources des EJB ainsi que les serveurs JBoss AS (répertoire jboss ).
VII-C. Lancement des serveurs JBoss AS▲
Chaque serveur doit être lancé dans un terminal. Cela permet d'agencer les fenêtres afin de suivre les traces des traitements qui s'exécutent :
? run-serveur-TL.bat (ou .sh ) pour le serveur des traitements par lots ;
? run-serveur-TI.bat (ou .sh ) pour le serveur des traitements interactifs ;
? run-serveur-TI-TL.bat (ou .sh ) pour le serveur qui basculera de l'un vers l'autre.
VII-D. Déploiement des composants▲
Le fichier de commande deploy.bat (ou .sh ) permet de déployer tous les composants (EJB, Queues…).
VII-E. Tout est prêt : jouons !▲
Toujours dans des fenêtres dédiées, lancez les clients TI et TL. Agencez vos fenêtres comme montré ci-dessous. Ainsi vous devez voir le client TI qui utilise les deux serveurs en cluster successivement (politique Round-Robin ). La console de chacun de ces serveurs le confirme. Les messages générés par le client TL ne sont traités que par le serveur TL pour le moment.
16:22:44,879 INFO [STDOUT] noel-laptop[noeud_ti_tl]-3 loop : 8
16:22:46,883 INFO [STDOUT] noel-laptop[noeud_ti_tl]-3 loop : 9
Dans la console du nœud_ti , on voit les messages de la détection de la modification du cluster. La nouvelle liste de nœuds est constituée. On peut remarquer que ce nœud traite la requête numéro 4, puis 5. C'est le comportement attendu, car le nœud_ti est désormais le seul dans le cluster.
VII-F. Arrêt de la partition : 1 - stopDefaultPartition.bat (.sh)▲
Dans ce script, nous utilisons l'outil twiddle permettant d'envoyer des requêtes JMX en ligne de commande. Dès que le nœud_ti_tl est sorti du cluster, on remarque qu'il termine le travail en cours, puis qu'il n'affiche plus les messages de l'EJB Stateless dans sa console.
16:22:28,846 INFO [STDOUT] noel-laptop[noeud_ti_tl]-3 loop : 0
16:22:30,850 INFO [STDOUT] noel-laptop[noeud_ti_tl]-3 loop : 1
16:22:32,854 INFO [STDOUT] noel-laptop[noeud_ti_tl]-3 loop : 2
16:22:33,960 INFO [DefaultPartition] Closing partition DefaultPartition
16:22:34,858 INFO [STDOUT] noel-laptop[noeud_ti_tl]-3 loop : 3
16:22:35,216 INFO [DefaultPartition] Partition DefaultPartition closed.
16:22:36,863 INFO [STDOUT] noel-laptop[noeud_ti_tl]-3 loop : 4
16:22:38,867 INFO [STDOUT] noel-laptop[noeud_ti_tl]-3 loop : 5
16:22:40,871 INFO [STDOUT] noel-laptop[noeud_ti_tl]-3 loop : 6
16:22:42,875 INFO [STDOUT] noel-laptop[noeud_ti_tl]-3 loop : 7
16:22:44,879 INFO [STDOUT] noel-laptop[noeud_ti_tl]-3 loop : 8
16:22:46,883 INFO [STDOUT] noel-laptop[noeud_ti_tl]-3 loop : 9
16:22:24,830 INFO [STDOUT] noel-laptop[noeud_ti]-2 loop : 8
16:22:26,834 INFO [STDOUT] noel-laptop[noeud_ti]-2 loop : 9
16:22:34,914 INFO [DefaultPartition] New cluster view for partition DefaultPartition (id: 2, delta: -1) : [55.2.4.47:1199]
16 :22:34,915 INFO [DefaultPartition] I am (55.2.4.47:1199) received membershipChanged event:
16:22:34,915 INFO [DefaultPartition] Dead members: 1 ([55.2.4.47:1299])
16:22:34,915 INFO [DefaultPartition] New Members : 0 ([])
16:22:34,916 INFO [DefaultPartition] All Members : 1 ([55.2.4.47:1199])
16 :22:34,919 INFO [ProxyFactory] Bound EJB Home ‘StatelessEjb' to jndi ‘TestCluster/ejb/StatelessEjb'
16:22:48,895 INFO [STDOUT] noel-laptop[noeud_ti]-4 loop : 0
16:22:50,899 INFO [STDOUT] noel-laptop[noeud_ti]-4 loop : 1
16:22:52,903 INFO [STDOUT] noel-laptop[noeud_ti]-4 loop : 2
16:22:54,907 INFO [STDOUT] noel-laptop[noeud_ti]-4 loop : 3
16:22:56,912 INFO [STDOUT] noel-laptop[noeud_ti]-4 loop : 4
16:22:58,916 INFO [STDOUT] noel-laptop[noeud_ti]-4 loop : 5
16:23:00,920 INFO [STDOUT] noel-laptop[noeud_ti]-4 loop : 6
16:23:02,924 INFO [STDOUT] noel-laptop[noeud_ti]-4 loop : 7
16:23:04,928 INFO [STDOUT] noel-laptop[noeud_ti]-4 loop : 8
16:23:06,932 INFO [STDOUT] noel-laptop[noeud_ti]-4 loop : 9
16:23:08,944 INFO [STDOUT] noel-laptop[noeud_ti]-5 loop : 0
16:23:10,948 INFO [STDOUT] noel-laptop[noeud_ti]-5 loop : 1
Du côté du client, on remarque que seule la trace provenant du nœud_ti s'affiche.
run-ejb:
[java] Demarrage : 0
[java] [Thread-0] : noel-laptop[noeud_ti]-0
[java] [Thread-0] : noel-laptop[noeud_ti_tl]-1
[java] [Thread-0] : noel-laptop[noeud_ti]-2
[java] [Thread-0] : noel-laptop[noeud_ti_tl]-3
[java] [Thread-0] : noel-laptop[noeud_ti]-4
[java] [Thread-0] : noel-laptop[noeud_ti]-5
[java] [Thread-0] : noel-laptop[noeud_ti]-6
[java] [Thread-0] : noel-laptop[noeud_ti]-7
[java] [Thread-0] : noel-laptop[noeud_ti]-8
La console du nœud_tl ne change pas de comportement, les MDB locaux traitent les messages du client TL.
VII-G. Activation des MDB : 2 - startDelivery.bat (.sh)▲
Sur le nœud_ti_tl , le pool de MDB commence à traiter des messages de la queue. Ce travail est désormais partagé avec le nœud_tl . Le nœud_ti , quant à lui, continue à être le seul à répondre au client TI.
INFO [STDOUT] noel-laptop[noeud_ti_tl]-3 loop : 6
INFO [STDOUT] noel-laptop[noeud_ti_tl]-3 loop : 7
INFO [STDOUT] noel-laptop[noeud_ti_tl]-3 loop : 8
INFO [STDOUT] noel-laptop[noeud_ti_tl]-3 loop : 9
INFO [STDOUT] >>>>> [Thread: JMS SessionPool Worker-0] Working .... i == 0
INFO [STDOUT] >>>>> [Thread: JMS SessionPool Worker-1] Working .... i == 0
INFO [STDOUT] >>>>> [Thread: JMS SessionPool Worker-0] Working .... i == 1
INFO [STDOUT] >>>>> [Thread: JMS SessionPool Worker-1] Working .... i == 1
VII-H. Désactivation des MDB : 3 - stopDelivery.bat (.sh)▲
Nous désactivons les MDB du nœud_ti_tl . Les traitements en cours se terminent normalement. Seuls les deux autres nœuds travaillent.
VII-I. Redémarrage de la partition : 4 - startDefaultPartition.bat (.sh)▲
Après le lancement de la commande de redémarrage de la partition, le client montre que le travail est désormais distribué aux deux nœuds du cluster.
[java] [Thread-0] : noel-laptop[noeud_ti]-6
[java] [Thread-0] : noel-laptop[noeud_ti]-7
[java] [Thread-0] : noel-laptop[noeud_ti]-8
[java] [Thread-0] : noel-laptop[noeud_ti_tl]-9
[java] [Thread-0] : noel-laptop[noeud_ti]-10
[java] [Thread-0] : noel-laptop[noeud_ti_tl]-11
[java] [Thread-0] : noel-laptop[noeud_ti]-12
La console du nœud_ti_tl montre les messages liés au démarrage de la partition HA, puis affiche les messages de l'EJB stateless. Ici la requête numéro 9 du client est prise en charge.
-------------------------------------------------------
GMS: address is noel-laptop:32958 (additional data: 14 bytes)
-------------------------------------------------------
16:24:25,407 INFO [DefaultPartition] Number of cluster members: 2
16:24:25,407 INFO [DefaultPartition] Other members: 1
16 :24:25,408 INFO [DefaultPartition] Fetching state (will wait for 30000 milliseconds):
16 :24:25,409 INFO [DefaultPartition] New cluster view for partition DefaultPartition: 3 ([55.2.4.47:1199, 55.2.4.47:1299] delta: 0)
16 :24:25,486 INFO [DefaultPartition] I am (55.2.4.47:1299) received membershipChanged event:
16:24:25,486 INFO [DefaultPartition] Dead members: 0 ([])
16:24:25,487 INFO [DefaultPartition] New Members : 0 ([])
16 :24:25,487 INFO [DefaultPartition] All Members : 2 ([55.2.4.47:1199, 55.2.4.47:1299])
16 :24:25,533 INFO [HANamingService] Started ha-jndi bootstrap jnpPort=1300, backlog=50, bindAddress=/0.0.0.0
16 :24:25,535 INFO [DetachedHANamingService$AutomaticDiscovery] Listening on 0.0.0.0/0.0.0.0:1102, group=230.0.0.4, HA-JNDI address=55.2.4.47:1300 16 :24:25,585 INFO [ProxyFactory] Bound EJB Home ‘StatelessEjb' to jndi ‘TestCluster/ejb/StatelessEjb'
16:24:25,603 INFO [FarmMemberService] **** pullNewDeployments ****
16:24:29,161 INFO [STDOUT] noel-laptop[noeud_ti_tl]-9 loop : 0
16:24:31,165 INFO [STDOUT] noel-laptop[noeud_ti_tl]-9 loop : 1
Dans la console du nœud_ti , les messages liés à la reconstitution du cluster, suite à la détection du nouveau nœud, apparaissent. Le nœud traite la requête numéro 8 puis 10. La distribution du travail sur les deux nœuds est prise en charge automatiquement.
16:24:23,124 INFO [STDOUT] noel-laptop[noeud_ti]-8 loop : 7
16:24:25,128 INFO [STDOUT] noel-laptop[noeud_ti]-8 loop : 8
16 :24:25,403 INFO [org....HAPartition.lifecycle.DefaultPartition] New cluster view for partition DefaultPartition (id: 3, delta: 1) : [55.2.4.47:1199, 55.2.4.47:1299]
16 :24:25,404 INFO [org.jboss...DefaultPartition] I am (55.2.4.47:1199) received membershipChanged event:
16:24:25,405 INFO [org.jboss...DefaultPartition] Dead members: 0 ([])
16 :24:25,405 INFO [org.jboss...DefaultPartition] New Members : 1 ([55.2.4.47:1299])
16 :24:25,405 INFO [org.jboss...DefaultPartition] All Members : 2 ([55.2.4.47:1199, 55.2.4.47:1299])
16:24:27,132 INFO [STDOUT] noel-laptop[noeud_ti]-8 loop : 9
16:24:49,213 INFO [STDOUT] noel-laptop[noeud_ti]-10 loop : 0
16:24:51,217 INFO [STDOUT] noel-laptop[noeud_ti]-10 loop : 1
16:24:53,222 INFO [STDOUT] noel-laptop[noeud_ti]-10 loop : 2
VIII. Conclusion▲
Dans cet article, nous avons vu comment installer plusieurs instances (3) de JBoss AS sur une seule machine. Parmi ces trois instances, deux forment un cluster, l'autre héberge un serveur JMS. Nous avons également vu l'intérêt de la présence d'un bus JMX permettant l'accès aux attributs et méthodes des MBeans qui sont la base de l'architecture de JBoss AS. Il faut noter la simplicité avec laquelle cet article met en œuvre ces services de haut niveau. Dans le cadre de projets critiques, cette simplicité permet de se concentrer sur le problème à traiter et non sur la mise en œuvre technique des services de base de la solution.