OpenMQ – Retour d'expérience
J.MOLIERE – Mentor/J
jerome@javaxpert.com
jerome.moliere@gmail.com

Sommaire
Contexte
●
Métier
–
Technique
–
Solution technique mise en oeuvre
●
Maquette réalisée
–
Configuration MQ
–
Résultats obtenus
–
Problèmes rencontrés
–

Contexte
Intervention en clientèle
●
Start-up montpelliéraine
–
Middleware dans le monde bancaire,
–
déclenchement de transactions bancaires
à partir de traitements métier suite à des
opérations télécom
–

Contexte technique (1)
JMS acteur central
●
Déclenche les traitements métier
–
Garant de la fiabilité du système
–
Pas de perte de messages ==> €!!!
●
Un message n'est nullement correlé à un autre
–
Toute information perdue l ' est définitivement
–
1 message perdu implique perte de chiffre pour le
–
client
Doit etre à meme de supporter une évolution de
●
la charge
Sans remettre en cause l'architecture technique
–
Par simple mise à disposition de nouvelles
–
machines
Réalisme entre matériel et ressources CPU/disque
–

Contexte technique(2)
Avant intervention:
●
Utilisation du Spring Template JMS
–
Trop intrusif – gestion des pools de
●
ressources par le framework plutot que
déléguée au moteur JMS
Architecture JMS
–
Utilisant ActiveMQ (Apache)
●
Perte de messages
–
Aucune redondance (HA)
–
Aucun lissage de charge (load balancing)
–
Fonctionnalités déjà présentes dans ActiveMQ
–
mais relevant du stade de l'incubation et pas
de la production!!!

Contexte technique(3)
Après intervention:
●
Recentrage architectural
–
Briser les dépendances inutiles (Spring JMS par
●
exemple)
Réalisation d'une réelle encapsulation de la
●
couche de gestion des messages
Robustesse de la solution
–
Plus de perte de messages
●
Objectif principal atteint vis à vis du client!!!
–
Mais :
–
Pas de réel load balancing (bug dans la 4.2
●
OpenMQ)

Solution technique mise en
oeuvre
Mise en place d'un environnement de test dédié
●
Virtualisation avec Virtualbox
–
Simplicité de mise en oeuvre
●
Donc peu de temps alloué pour cette mise ne
–
oeuvre et donc peu de budget pour le client!!
Création d'un réseau virtuel dans mon laptop
●
dédié à cette maquette
Aspect performance peu impactant, priorité mise
●
sur la robustesse donc les gains de
performance de solutions comme (KVM ou
XEN) étaient peu intéressants....

Solution technique mise en
oeuvre(2)
Schéma architectural de la maquette
●
–

Solution technique mise en
oeuvre
(3)
Configuration OpenMQ 4.2 en mode HA
●
Utilisation d'un serveur de base de données
–
dédié dans le cas de la démonstration:
javadb aka derby
Mode HA:
–
Pas de réel noeud maitre en théorie
●
Stockage des messages en base dans un
●
schéma dédié
Heartbeat entre les noeuds pour découverte à
●
chaud des noeuds vivants dans la grappe
(cluster).

Solution technique mise en
oeuvre (4)
Gestion des acquittements coté client
●
Divers choix cf specs JMS
–
NONE
●
AUTO
●
CLIENT
●
Adoption d'un acquittement client
–
systématique
Permet maitrise des traitements des
●
messages
Messages non acquittés sont naturellement
●
délivrés de nouveau (TTL)

Solution technique mise en
oeuvre (5)
Acquittement des messages
●
Utilise une API propriétaire au MQ pour éviter
–
un bug comportemental provenant de la
méthode acknowledge()
Cast du javax.jms.Message en la classe
–
d'implémentation de Sun pour pouvoir
appeler la méthode
acknowledgeThisMessage()
Évite l'acquittement de tous les messages y
–
compris de celui-ci!!!
On ne veut en acquitter qu'un seul!!!
–

Solution technique mise en
oeuvre(6)
Configuration du broker en détail
●
Principe mis en oeuvre:
–
Faciliter l'ajout de noeuds dans la grappe
●
Avoir des configurations similaires d'un broker
●
à l'autre
Noeuds iso-fonctionnels
–
Utilisation d'un fichier commun à tous les
●
brokers et ajout des seules différences dans
le fichier de config de chaque broker
Utilisation d'un montage NFS/Samba ou
–
comme ici d'une zone d'échange VirtualBox

Solution technique mise en
oeuvre(7)
Configuration des brokers en détail
●
Fichier d'un noeud de la grappe réduit au
–
strict minimum (ici noeud dénommé
broker2)
imq . b r o k e r i d=b r o k e r 2
–
imq . i n s t a n c e c o n f i g . v e r s i o n =300
–
imq . c l u s t e r . u r l= f i l e \\ : / / / r o o t /mq_common . p r o p e r t i e s
–
–

Solution technique mise en
oeuvre (8)
Configuration du broker en détail
●
Fichier commun
–
Fichier référencé depuis les brokers mis à
–
disposition sur un filesystem partagé
Beaucoup de propriétés pas toutes
–
commentées....
Ici on va segmenter en blocs pour la lisibilité
●

Solution technique mise en
oeuvre(9)
Configuration du broker en détail
●
Définition d'un seul et meme cluster
–
–

Solution technique mise en
oeuvre(10)
Configuration du broker en détail
●
Définition du type de persistance
–
Ici utilisation d'une base de données Derby
●
sur une machine virtuelle Virtuelle (Debian
etch) nommée derbyserver et proposant un
schéma de base nommé hadb
imq . p e r s i s t . s t o r e=j d b c
●
imq . p e r s i s t . j d b c . dbVendor=derby
●
imq . p e r s i s t . j d b c . derby . d r i v e r=o r g . apache . derby . j d b c . C l i e n t D r i v e
●
r
imq . p e r s i s t . j d b c . derby . o p e n d b u r l=j d b c : derby : / / d b s e r v e r : 1 5 2 7 /
●
hadb \\\\
; c r e a t e=t r u e
●
●
–

Résultats obtenus
Robustesse des brokers
●
Aucun message perdu sur des tirs d'une dizaine
–
d'heure (centaine de milliers de messages)
sur de petites configurations
Image virtuelle simulant un proc 1Ghz avec
●
512Mo RAM dédiés
Performance : environ 30 messages traités /
●
seconde en pic
Seule alerte : cas de passages répétés du GC en
●
mode full
Tuning de la JVM
–
Ou augmentation des ressources dédiées à la JVM
–

Résultats obtenus(2)
Robustesse:
●
Pas eu le loisir de voir basculer les
–
indicateurs d'état de santé des brokers
3 niveaux implémentés dans OpenMQ
●
Vert
–
Orange
–
Rouge
–
Censés définir des politiques de
●
comportement des brokers
Pas validé!!!!
–

Résultats obtenus(3)
Suite aux tests
●
contact/mail avec l'équipe OpenMQ
–
Suivi d'un entretien avec Linda Schneider à
–
Paris
Remarques prises en compte par l'équipe
–
OpenMQ et intégrées dans la roadmap du
produit
Bug empechant le load balancer fixé en 4.3
●
Gros travail en 4.3 sur le schéma de base
●
Amélioration de la console d'administration en
●
4.5 (surtout pour le mode cluster)

Résultats obtenus(4)
Avec la refonte architecturale induite par
●
cette mission
Création d'une réelle couche d'isolation vis à
–
vis du broker
Injection de la configuration du broker au
–
démarrage du produit
Création des destinations …
●
Point souvent négligé !!!!
–
JMS n'a pas d'API normalisée dédiée à
●
l'administration

Problèmes rencontrés
Techniques:
●
Non intégration en production avec Hermes
–
JMS (souci dans le nommage des
propriétés des classes)
Schéma de base et accesseurs aux bases
–
introduisant des locks !!!
Fonctionnement en mode stress avec une
–
petite JVM
Load balancer
–

Problèmes rencontrés(2)
Documentation du produit
●
Quelques soucis d'alignement de version
–
Richesse des propriétés accessibles sur ce
–
produit
14 pages de properties!!!!
●
Trouver les bonnes!!!
●

Conclusion
Client satisfait
●
Produit Open Source parfait pour les tests
–
Support pour passage en production possible
–
Robustesse est au rendez vous
–
OpenMQ
●
Remontées techniques prises en compte et
–
accessibilité de l'équipe OpenMQ
Produit fiable et maturité...
–
Roadmap avec une release tous les 3 mois!!!
–

Conclusion(2)
Bugs
●
Assez peu
–
Pris en compte dans les versions ultérieures
–
ou fix packs si choix de rester en 4.2
Performance
●
Nouveaux tests nécessaires à faire en 4.3
–
car quelques soucis réglés avec cette
version

Pointeurs
https://mq.dev.java.net
●
http://activemq.apache.org
●
http://developers.sun.com/javadb/
●
http://java.sun.com/products/jms/docs.html
●

Annexes
Extrait de code de la méthode onMessage()
●
d'un client....
Initialisation du schéma de base de données
●
et démarrage de Derby(aka javadb)

Extrait du code d'un client
● i f ( ! ( a r g 0 instanceof MessageObject ) ) {
logger . error (
●
\" Unable t o e x t r a c t MessageObject from message ! ! ! \"
●
);
●
}
●
else {
●
MessageObject o b j = ( MessageObject ) a r g 0 ;
●
MessageTreatment t r e a t m e n t =
●
this . b u s i n e s s P r o c e s s o r . createMessageTreatment ( obj ) ;
●
treatment . treatMessage ( ) ;
●
try {
●
// HACK ! ! !
●

Extrait du code d'un client
● // j u s t send ack t o t h e e x t r a c t e d message and not a l l
// u n p r e v i o u s l y unACKNOWLEDGED
●
// NEED a bad c a s t t o do t h a t
●
com . sun . m e s s a g i n g . jms . Message msg=
●
( com . sun . m e ss a g i n g . jms . Message ) a r g 0 ;
●
msg . acknowledgeThisMessage ( ) ;
●
● i f ( logger . isInfoEnabled ()){
l o g g e r . i n f o ( \"Ok − acknowledge s e n t t o b r o k e r \" +
●
\" − message w i l l be s u p p r e s s e d ! ! \" ) ; }
●
} catch ( JMSException ex ) {
●
logger . error (
●
\" something went wrong w h i l e s e n d i n g ACK\" , ex ) ;
●
}
●
} // onMessage ( )
●

Initialisation du schéma de la
base de données
Utilisation d'un outil dédié fourni par
●
OpenMQ
Opération réalisée depuis n'importe lequel
–
d'entre vos brokers (iso-fonctionnels)
>imqdbmgr c r e a t e t b l
–
Va créer le schéma utilisé pour la persistance des messages et la
–
HA!!!
Nécessite une base fonctionnant en réseau (cf doc Derby)
–
s t a r t N e t w o r k S e r v e r −h d b s e r v e r
●

Initialisation du schéma de la
base de données(2)
Modification du classpath des brokers pour contenir la
●
librairie derbyclient.jar permettant de communiquer avec
Derby!!!
–

Questions?
Elles sont bienvenues
●
Mais vite on est en retard et Alexis va raler!!!
–
●
●
●
Merci de votre attention
●