Blog#9

Je suis actuellement sur une mission de mise en oeuvre d’un environnement full JMS. Dans ce cadre, nous avons été amené à effectué quelques tests de charge, en nous basant notamment sur ceux fournis par JBoss Messaging 2.0 (encore en alpha version, mais les performances annoncées sont proprement ahurissantes !).

Pourtant, en cours de campagne, un doute m’étreint. Les chiffres obtenus par un client de test me semblent bizarrement incohérents avec ceux de ses congénères, pourtant codés de manière identique.

Je cherche, je tourne, j’expérimente, jusqu’à en arriver à mon test ultime : écrire volontairement une erreur et vérifier qu’elle est bien détectée par l’application.

Mon fichier « jndi.properties » est parfaitement classique (c’est d’ailleurs celui que l’on trouve en premier en cherchant sur Google):
java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
java.naming.provider.url=localhost:1099
java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces


Pourtant, lorsque je modifie le paramètre «java.naming.provider.url » avec un nom de serveur totalement faux (à moins qu’un facétieux ingénieur système n’ai nommé une machine « toto » :roll:), mon client de test marche toujours parfaitement : il envoie et reçoit des messages !

Pire, j’arrête alors mon serveur JMS et que je relance le client de test… celui-ci persiste à fonctionner correctement 88|!!!

Alors que je commence à sérieusement douter de ma santé mentale, je cherche sur le wiki JBoss , et là, surprise :

Automatic Discovery of HA-JNDI Servers

The org.jnp.interfaces.NamingContextFactory also features the ability to automatically discover naming servers running the JBoss HA-JNDI service. Discovery occurs when either no Context.PROVIDER_URL is specified, or no valid naming service could be located among the URLs specified. When discovery is attempted, a multicast packet will be sent out, requesting that any HA-JNDI servers reply with an announcement of their availability. If any replies are received, the NamingContext can then connect to the replying server.

Par défaut, en cas d’erreur ou d’absence du paramètre « java.naming.provider.url » (ce qui était le cas dans mon client de test, une bête faute de frappe), JBoss broadcaste sur le réseau à la recherche d’un autre serveur de nom. Autant dire qu’il en a trouvé sur le LAN (ils sont ici monnaie courante, notamment en environnement de développement/intégration). De plus, mon programme étant basé sur les destinations de tests créés par défaut par JBoss, tout se passait « bien » (sauf peut-être pour le serveur dont j’ai dû dégrader les performances avec mes tests de charge :oops:!!!).

Au final, il existe bien un paramètre pour empêcher ce genre de comportement, que je vous conseille donc d’inclure à vos fichiers « jndi.properties » :

jnp.disableDiscovery=true

Ca vous évitera peut-être d’envisager l’exorcisme de votre machine si elle se met à envoyer des messages alors que vous avez arrêté votre serveur JMS :>>

Hope this helps !