Un très ancien bug non découvert jusque là

Dans un billet où je tirais à boulets rouges sur le Copier/Coller, je mettais en évidence les inconvénients de cette pratique trop répandue.

Une fois n'est pas coutume, j'ai corrigé la semaine dernière un bug qui date d'au moins 2 ans, sur une implémentation JMS, bug qui n'avait pas été encore découvert car la plupart des utilisateurs d'applications JMS (comme les autres d'ailleurs) utilisent le Copier/Coller à outrance !

Le problème était le suivant.

Si l'on fermait le contexte JNDI juste après les appels aux lookup() JNDI des queue et queue connection factory, les connexions JMS échouaient par la suite !

C'est à dire que les connexions JMS avaient besoin du contexte JNDI pour se connecter au queue manager JMS, ce qui est une erreur.

Si ce bug n'a pas été découvert plus tôt, c'est parce que la majorité des programmes d'exemples JMS ferment le contexte JNDI en même temps que les autres ressources de l'application JMS, et non après les opérations de lookup() JNDI, ce qui serait la manière logique de faire.

Donc, pour une fois, merci au Copier/Coller !

Cela dit, de manière générale, je préconise généralement de ne pas fournir de programmes d'exemples dans les livrables d'un logiciel, car, malgré les avertissements d'usage dans les cartouches d'entête des fichiers, les utilisateurs et programmeurs utilisent trop souvent ces programmes d'exemples comme templates de base à leurs développements.

Autres posts liés à Développement / Logiciel / Java / Shell / C:

Erreurs de débutant en Java: fermer les fichiers !
Heure d'été, Classe Date, JDK 1.5 et TimeZone
pop3/tcp server failing (looping), service terminated
De l’usage des programmes d’exemple
JavaMail en IMAP avec un serveur Exchange

Installer MQ Series 5.3 sur Linux Debian

MQ Series 5.3, la version 6.0 également il me semble, est livré sous Linux pour une distribution Red Hat (et aussi Suse).

Pour installer MQ Series 5.3 sous Red Hat on pourra utiliser le lien précédent.

Néanmoins, il est possible d'installer MQ Series sous Debian gràce à l'utilitaire Debian alien.

alien est en effet capable non seulement d'installer un package .rpm sur une distribution Debian, mais aussi de générer le fichier .deb correspondant, typique des archives de la Debian.

La procédure d'installation de MQ Series 5.3 sous Debian est la même que sous Red Hat en ce qui concerne la création des utilisateurs et des groupes MQ Series, l'installation des packages, la création d'un queue manager MQ Series et des files d'attentes, etc ...

En revanche, pour installer les packages .rpm de MQ Series, il vaut mieux générer auparavant les fichiers .deb avec alien et les installer ensuite avec dpkg plutôt que de tout faire avec alien.

En effet, les scripts de post installation de MQ Series échouent si l'on utilise alien -idv nom_du_package_mq_series_rpm ; en particulier les commandes chown ne sont pas exécutées et on se retrouve avec une arborescence /opt/mqm qui appartient à root.

On procèdera comme suit:

alien -cdv nom_du_package_mq_series_rpm

c pour scripts,
d pour conversion de l'archive .rpm en .deb,
v pour verbose

Une fois cette commande lancée, on obtient le fichier .deb qu'il suffit d'installer avec la commande dpkg -i nom_du_package_mq_series_deb

Il se peut qu'alien ne prenne en entrée qu'un fichier avec une extension .rpm ; dans le cas contraire on obtiendra une erreur du genre "Unknown type of package, jdk-1_5_0_12-linux-i586-rpm".

Lorsque les packages MQ Series 5.3 sont installés, il ne faut surtout pas oublier d'installer les derniers patchs MQ Series.

Sinon la création d'un queue manager MQ Series semble fonctionner mais crtmqm sort en Segmentation Fault et il n'est pas possible de démarrer le queue manager !

De l’usage des programmes d’exemple

Un utilisateur m’appelle pour une question sur l’implémentation JMS dans le middleware orienté message sur lequel je travaille.

Il m’envoie un bout de code et me demande ce qui ne va pas dans son code, et pourquoi il perd des messages.

Je me rends compte que comme la majorité des exemples d’appels à un provider JMS que l’on trouve sur le net, sa session est non transactionnelle en AUTO_ACKNOWLEDGE.

Donc, si son applicatif s’arrête entre la réception du message et avant le traitement de ce dernier, le message est “perdu” puisque commité par le queue manager (AUTO_ACKNOWLEDGE !) et non traité par l’application !

Pourquoi est-ce que dès que les développeurs ont 15 lignes de code à écrire, il leur faut un exemple ?

Normalement, c’est leur métier d’écrire des programmes, ils ne devraient pas avoir des sueurs devant une page blanche !

L’exemple n’a rien de mauvais en soi, mais ce que je lui reproche, c’est l’utilisation qui en est faites la plupart du temps: si on prend un exemple pour aller plus vite dans son travail, sans prendre le (peu de) temps nécessaire pour savoir ce que l’exemple fait ou ne fait pas, au final, au lieu de gagner du temps, on en perds !

Et beaucoup plus que ce qu’on pensait gagner initialement.

Utiliser un exemple est une bonne chose, mais pas si on l’utilise comme une boite noire et surtout sans réfléchir.

Après, l’étape suivante, c’est de poster un message sur les forums: “voilà, je fais ça, ça a l’air bon mais ça ne marche pas … Est-ce quelqu’un peut m’aider ?” ….

Enfin, malheureusement, les exemples sont rarement faits pour résoudre précisément votre problème, sinon la vie serait trop belle, et puis il faut lire (un minimum) la Javadoc JMS.

Autres posts liés à Développement / Logiciel / Java / Shell / C:

Erreurs de débutant en Java: fermer les fichiers !
Heure d'été, Classe Date, JDK 1.5 et TimeZone
Un très ancien bug non découvert jusque là
pop3/tcp server failing (looping), service terminated
JavaMail en IMAP avec un serveur Exchange

JavaMail en IMAP avec un serveur Exchange

Accéder à un compte IMAP avec JavaMail ne pose à priori pas de problèmes.

J’étais en train de tester un bridge entre un MOM JMS et des serveurs Mails divers et variés, quand je me suis mis à tester sur Exchange, le serveur de Microsoft.

Sur Exchange, surprise à l’ouverture du Folder IMAP, la mailbox n’existe pas !
Ah bon, pourtant, j’ai un user valide et je suis connecté.

La raison de l’erreur dont la stack suit:

Exception occurred: javax.mail.MessagingException: A2 NO There is no replica for that mailbox on this server.;
nested exception is:
com.sun.mail.iap.CommandFailedException: A2 NO There is no replica for that mailbox on this server.
at com.sun.mail.imap.IMAPFolder.doCommand(IMAPFolder.java:2125)
at com.sun.mail.imap.IMAPFolder.exists(IMAPFolder.java:406)
at com.sun.mail.imap.IMAPFolder.checkExists(IMAPFolder.java:280)
at com.sun.mail.imap.IMAPFolder.open(IMAPFolder.java:779)

est que le serveur Exchange me redirigeait vers un deuxième serveur pour m’authentifier, et utilisait le premier (celui que je lui avais donné à la connexion) pour ouvrir la INBOX.

Manque de chance, la INBOX n’existe (normal) que sur le deuxième serveur (celui que j’ignorais) !

Moralité, si vous rencontrez la belle erreur “There is no replica for that mailbox on this server", pensez à mettre les traces IMAP et regardez si vous ne voyez pas passer un autre nom de serveur ; c’est celui-ci qu’il faudra utiliser.

Les développeurs de chez Microsoft pourraient étoffer le message d’erreur, par exemple: “you’ve been redirected for authentification, please check serveur name” !

Les devéloppeurs ne pensent jamais assez à l’utilisateur final …

Autres posts liés à Développement / Logiciel / Java / Shell / C:

Erreurs de débutant en Java: fermer les fichiers !
Heure d'été, Classe Date, JDK 1.5 et TimeZone
Un très ancien bug non découvert jusque là
pop3/tcp server failing (looping), service terminated
De l’usage des programmes d’exemple