Revue de Presse Xebia

La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.

Actualité éditeurs / SSII

• HornetQ 2.1

Le coin de la technique

• Git podcastcodé
• Fuites mémoires dans Tomcat

Actualité éditeurs / SSII

HornetQ 2.1

La version 2.1 d’HornetQ est sortie la semaine dernière. Trois nouvelles fonctionnalités importantes ont été apportées :

• La possibilité de regrouper des petits messages, au niveau du protocole TCP, dans un seul envoi
• Ajout du protocole STOMP, un protocole de messagerie texte très simple mais qui a l’avantage de s’adapter à de nombreuses plateformes et langages.
• Implémentation de l’API WebSocket pour STOMP. WebSocket est apparu avec la nouvelle norme HTML5 et propose une normalisation de l’API javascript pour tout ce qui concerne le maintien d’une socket vers le serveur, reprenant le principe de Comet.

Ces deux derniers points sont aussi prévus dans la version 5.3.4 d’ActiveMQ.

Dans la roadmap de la version 2.2 :

• Rest: accepter le protocole HTTP
• Serverless: un client HornetQ embarquant un serveur
• AMQP: implémentation de la version 1.0, pas encore finalisée, de ce protocole

Le coin de la technique

Git podcastcodé

Avec ce titre, nous voulons signaler que Git, le gestionnaire de versions décentralisé, a été mis à l’honneur du dernier épisode du podcast des Cast Codeurs. Emmanuel Bernard, de JBoss, interroge David Gageot d’Algodeal, qui utilise Git depuis 2 ans déjà, et nous livre quelques bons cas d’utilisation et exemples.
Alors quels sont les arguments utilisés pour vanter ce DVCS ? Ce qui ressort c’est surtout le gain de temps et le fait que Git ne se met pas en travers du chemin de ses utilisateurs. Les commits sont rapides car en local, et seuls les changements sont commités, pas les versions finales des fichiers. Un bénéfice qui en découle est que les développeurs sont ainsi poussés à commiter souvent. Git détecte aussi automatiquement les déplacements et renommages des fichiers , ce qui permet des refactorings agressifs.
Bien sûr, David Gageot évoque la question que tout le monde se pose: si la même ligne change à 2 endroits, que se passe-t-il alors ? Effectivement, ce cas doit être résolu manuellement, mais il précise que, grâce aux commits fréquents qu’encourage Git, et comme il se base sur les modifications successives, ce cas survient moins souvent.
Une méthodologie particulière, qui intéressera tous ceux qui ont déjà passé des heures à chercher quel commit avait été à l’origine d’un bug, est aussi décrite. Elle se base sur l’outil git-bisect pour détecter rapidement (par dichotomie) la révision où un bug est apparu. La description de cette fonctionnalité est assez bluffante !
En vrac, sont aussi évoqués:

• Git SVN qui permet de se faire la main en local sur Git tout en continuant d’utiliser le SVN de son équipe par exemple.
• Git Hub présenté comme la killer app de Git qui est en quelque sorte un Sourceforge 2.0, plus social.
• L’absence de vraie roadmap publique, justifiée par le développement qualifié d’organique, mais la bonne progression du projet n’en semble pas affectée.

Au final, une phrase qui résumera bien tout cet entretien est « Git, si tu as besoin de le vendre à ton manager, change de manager » :) . David Gageot entend par là montrer à quel point Git améliore la productivité.
Emmanuel Bernard semble d’ailleurs avoir été tellement convaincu qu’il vient de publier un article intitulé « Git: how my life has improved since last month when I used SVN ».
Et pour terminer sur Git, notons qu’InfoQ annonce les dernières versions des plugins Eclipse JGit et Egit. Jgit est la librairie Java permettant de communiquer avec un repository Git, alors que EGit est son frontend graphique permettant d’y accéder dans Eclipse. Il est précisé que le format étant standardisé, il est possible (voir recommandé, car le développement est encore en cours) d’utiliser ces plugins conjointement à Git version ligne de commande. C’est quelque chose qu’apprécieront les nombreuses personnes ayant déjà eu des problèmes suite à une montée de version de SVN en ligne de commande alors que les plugins SVN pour Eclipse, inchangés, étaient rendu non fonctionnels (voir corrompaient carrément les fichiers !).

Fuites mémoires dans Tomcat

Vous êtes en train de tester votre application qui tourne sur Tomcat depuis votre IDE mais vous aimeriez faire une petite modification sur votre contrôleur et vous êtes en build automatic. La compilation se met en marche et là, pas de chance, les piles d’erreurs s’accumulent dans votre console. Plus rien ne fonctionne, vous êtes bon pour redémarrer votre serveur.

Ce problème bien connu, du en général à des OutOfMemoryException, arrive car la dé-allocation des objets utilisés se passe mal, la pile PermGen de la JVM accumule les objets sans dégrossir provoquant des PermGen Exception. Une interview très intéressante de Mark Thomas, commiter sur Apache Tomcat, nous éclaire sur le pourquoi du comment et les améliorations prévues pour Tomcat 7.

D’après son expérience, les fuites mémoires sont surtout dues à des défauts dans les librairies utilisées. Tomcat affecte un classloader par application, lorsqu’une application est rechargée Tomcat tente d’abord de nettoyer tous les objets liés au classloader avant d’en affecter un nouveau. Si jamais pour une raison ou une autre un objet d’un autre classloader pointe vers celui qu’on veut supprimer, les objets ne peuvent être supprimer. Les API ou applications qui peuvent être responsables de cette situation sont en général :

• JDBC driver registration
• Some logging frameworks
• Storing objects in ThreadLocals and not removing them
• Starting threads and not stopping them

Pour corriger cela, Tomcat lance des méthodes de nettoyage ad hoc pour tous ces types de problème et si jamais ce n’est pas possible, trace précisément la cause du non dé-référencement.

Plus surprenant peut-être, les causes de fuites mémoires sont parfois provoquées par la JRE elle-même. Dans ce cas Tomcat va tenter d’intercepter ces appels directs à la JVM pour pouvoir contrôler par la suite son référencement. On apprend à l’occasion que l’implémentation de java.util.logging dans la JRE n’est pas gérée par un classloader classique et Tomcat doit la surcharger.

Cet interview donne une idée assez claire de ce qui se passe dans Tomcat au moment du chargement d’une application. Les curieux peuvent étudier les classes WebappClassLoader (surtout la méthode clearReferences()) et JreMemoryLeakPreventionListener pour connaitre un peu mieux le fonctionnement interne. Tomcat 7 devrait apporter de nombreuses améliorations qui, bonne nouvelle, ont été aussi backportées sur la version 6.0.24 et donc déjà disponible.