Outils

• Helios, Eclipse 3.6

SOA

• Tomcat Stats: administrer Tomcat depuis son iPhone

Le coin de la technique

• Articles sur Groovy/Spring et Grails/Hibernate
• Un nouveau top 10 orienté performance

Agilité

• Happy birthday Post-It !

Outils

Helios, Eclipse 3.6

Après avoir épuisé les principales lunes de Jupiter (Callisto, Europa, Ganymède, Galileo), voici venu le tour d’Helios pour incarner la version annuelle d’Eclipse. Cette livraison ne contient pas moins de 39 projets de la fondation Eclipse et les supports pour Windows7, Ubuntu 10.04 et PowerPC 64 bit ont été ajoutés.

Pour ceux qui aiment ajouter une multitude de plugins à leur Eclipse, au lieu de passer par le « Install new software… », un lien direct vers le Marketplace permet très facilement d’installer ces plugins, un peu à la manière d’un plugin Firefox (tout comme le redémarrage obligatoire). L’ancienne méthode marche toujours pour les applications qui ne se trouvent pas sur le Marketplace. Et sûrement que les fans de DVCS (Distributed Version Control System) vont se précipiter sur le plugin EGit/JGit pour gérer ses sources sous Git, JGit étant l’implémentation full java utilisée également sur d’autre projets alors qu’EGit est sa surcouche pour Eclipse. Le résultat est assez prometteur.

En ce qui concerne uniquement Java, quelques petites améliorations ont été apportées:

• Les options du formatter acceptent plus de sémantiques comme les annotations, la déclaration de méthodes ou la possibilité de désactiver le formatter d’une partie du code (intéressant pour aider des merges compliqués).
• Les fonctionnalités sur le breakpoint, comme l’ajout d’une condition ou le compteur, sont à présent directement accessibles dans le panel breakpoints et non plus en passant par un menu contextuel dans le code.

La version 3.7 devrait surtout se concentrer sur Java7. Ian Bull d’Eclipse propose un top ten intéressant pour faire le tour des fonctionnalités. Arrive en tête l’application Xtext qui permet d’écrire son propre DSL puis de générer à partir de celui-ci son propre éditeur Eclipse contenant la complétion et différents outils pour coder dans ce nouveau langage. Une affaire à suivre.

Mais malgré toutes les nouvelles fonctionnalités, Helios sera surtout scruté pour les multiples bugs corrigés, sa gourmandise en RAM et sa stabilité, ce que seule une pratique intensive pourra valider. Alors à vos souris !

SOA

Tomcat Stats: administrer Tomcat depuis son iPhone

MuleSoft, plus connu pour son ESB Open Source Mule, a récemment annoncé la sortie de Tomcat Stats, la première application de monitoring Tomcat pour iPhone. Cette application gratuite vient enrichir l’offre de support également gratuite, proposée par MuleSoft depuis maintenant presque une année. L’application permet à un administrateur de gérer à distance plusieurs instances de Tomcat, qu’elles soient installées au sein de l’infrastructure propre de l’entreprise ou dans le Cloud. L’ensemble des informations critiques des serveurs administrés pourra alors être consulté depuis l’application, notamment l’utilisation mémoire, les statistiques sur le traffic Web, ainsi que le statut du serveur.

Pour télécharger l’application, rien de plus simple il suffit de se rendre sur l’App Store, directement depuis son mobile, ou sur iTunes à l’adresse suivante : Tomcat Stats By MuleSoft Inc.

Bien qu’un peu gadget, et pas vraiment indispensable, cette application iPhone offrira toujours aux administrateurs la possibilité de prolonger leur pause café sans avoir à culpabiliser.

Le coin de la technique

Articles sur Groovy/Spring et Grails/Hibernate

IBM developerWorks nous a récemment gratifié d’un article en 2 parties intitulé « GroovierSpring ». Dans la première partie, nous apprenons à définir des beans Spring en Groovy. Quatre méthodes sont à notre disposition:

• Utilisation de classes Groovy compilées en .class normaux
• Utilisation de classes Groovy directement sous forme de .groovy
• Utilisation de scripts Groovy en ligne, écrits dans la configuration Spring
• Utilisation de Bean Builder de Grails

Cette dernière possibilité permet de créer des beans dynamiquement, à partir de code Groovy. Cela sous entend que l’on peut, par le code, adapter les beans obtenus selon le contexte, les créer en utilisant des boucles, de la logique… C’est d’ailleurs une solution utilisée dans Grails.

Une fois les beans correctement définis, nous pouvons les utiliser comme n’importe quel bean Java défini plus classiquement. Le fait que les beans soient à l’origine en Groovy est complètement transparent à l’application.
La seconde partie de l’article va plus loin en explorant le rechargement à chaud des beans Groovy. C’est une plus-value importante: qui n’a jamais rêvé de pouvoir changer facilement certains bouts de code soumis aux désirs changeants des clients (ou à des bugs récurrents !) ? De plus, l’article propose une implémentation permettant de stocker son code Groovy en base de donnée, car il n’est pas toujours évident d’accéder au système de fichier des applications en production. C’est une idée assez peu conventionnelle ! D’ailleurs, le paragraphe de fin, intitulé « When Groovy scripts go bad », constitue une mise en garde pour ne pas abuser de ces possibilités, et être conscient des problèmes de sécurité soulevés.

Tant que nous somme dans le monde de Groovy, il nous semble intéressant de vous indiquer un article du blog de SpringSource qui s’intitule « GORM Gotchas (Part 1) ». Il pointe du doigt des comportements de GORM (la couche de persistance de Grails basée sur Hibernate) pouvant sembler bizarres. Les habitués d’Hibernate n’apprendront pas grand choses, mais l’article éclairera sans doutes ceux qui, attirés par la simplicité de Grails, se sont mis à l’utiliser sans expérience préalable d’Hibernate. Ils comprendront ainsi pourquoi leurs objets ne sont pas toujours sauvegardés immédiatement malgré un appel à « save() », et pourquoi ils le sont parfois en l’absence d’appel à cette même méthode. Un autre article traitant de Grails et Hibernate nous vient de Ted Naleid. Celui-ci explique comment il a pu améliorer les performances de son batch en flushant la session Hibernate et en vidant une Map de validation utilisée par Grails en interne. Ces 2 opérations exécutées régulièrement au cours du batch lui ont permis de démultiplier les performances. Grails s’appuie sur Hibernate, et il est parfois bon de se remémorer le fonctionnement de celui-ci pour expliquer et remédier à des problèmes observés coté Grails !

Un nouveau top 10 orienté performance

Ce top10 se trouve sur le blog de l’éditeur Dynatrace. A travers ce que ses consultants ont pu voir chez leur client (on parle donc d’un top 10 sélectif, chez des clients qui avaient conscience d’avoir des problèmes et qui pouvaient se permettre de les diagnostiquer avec un outil comme Dynatrace), il dresse un panorama qu’il est bon de toujours avoir à l’esprit durant nos développements. Nous nous sommes permis de le compléter avec nos propres retours d’expérience.

• une base de données trop sollicitée, ce qui inclut des données requetées trop grandes, ou requetées plusieurs fois, ou encore de trop nombreuses requêtes pour rapatrier une seule donnée (problème des mauvais usage des ORM).
• une mauvaise programmation concurrente, avec un excès de synchronisation.
• un manque de compréhension des appels remote et donc un trop grand nombre d’appels.
• un mauvais usage des frameworks de mapping objet – relationnel. Ce point est largement répandu chez nos clients, en couvrant un large spectre, du simple problème de paramétrage à l’utilisation la plus hors de propos de la librairie.
• l’existence de fuite mémoire (mais pourquoi ce point n’a t’il pas été placé en premier ?)
• une librairie tierce coupable de mauvaises performance. Avec la multiplication des composants dans nos applications, le risque d’introduire des librairies moins robustes et moins performantes existe. Nous avons toujours trouvé étonnant de voir partir en production certains projets basés sur des librairies en béta…
• une mauvaise utilisation des ressources machine (CPU, I/O…). Un traitement prend 50 % de CPU pendant 2 ms. Pas de quoi fouetter un chat ? Multipliez le par 1000 utilisateurs, une consommation mémoire excessive entraînant de fréquents GC, et nous en reparlerons.
• des sites web trop chargés. La bande passante ne cesse d’augmenter, mais ce n’est pas une raison pour surcharger vos frontaux avec de nombreuses images trop volumineuses, des appels AJAX incessants, en ignorant joyeusement les stratégies de cache navigateur et/ou serveur.
• une mauvaise gestion de caching des objets en mémoire. Surchargez votre mémoire pour alléger votre base, et c’est le Garbage Collector qui vous rappellera à l’ordre.
• la sérialisation coute cher. Attention donc, si vous multipliez les appels RMI ou SOAP, à ne pas sérialiser trop d’objets, ou des objets trop volumineux.

Nous avons échangé les places du point n°10 et du point bonus. Le point n°10, même si il a une réalité tangible, nous paraissait un peu trop marketing (mais c’est en partie la raison de vivre d’un blog éditeur) et nous préférons le déplacer en bonus :

• le problème intermittent, invisible. C’est celui dont il faut se prémunir en multipliant les tests (fonctionnels, de charge) ou en étant idéalement outillé.

Agilité

Happy birthday Post-It !

Et pour conclure cette revue de presse, nous ne résistons pas à l’envie de partager avec vous cette nouvelle d’importance: les Post-It, ces fameuses petites notes collantes multicolores, fêtent leurs 30 ans. Rappelons que l’utilisation de Post-It est devenue partie intégrante de la pratique de Scrum. Comment mettre à jour facilement la liste des tâche d’un Sprint sans Post-It ?! Alors pour leur rendre hommage, regardons quelques photos ou encore cette magnifique vidéo de laquelle ils sont les acteurs majeurs. Bon anniversaire les p’tits gars !

Actualité éditeurs / SSII

• Où sont passées les stars de Sun ?

Le coin de la technique

• Nouvelle version pour EhCache
• jucProfiler
• Maven Enforcer

Actualité éditeurs / SSII

Où sont passées les stars de Sun ?

Un an après le rachat de Sun par Oracle, qu’est il advenu des stars de Sun ? La réponse est plutôt radicale : elles se sont envolées vers des cieux plus cléments. Avant d’entrer dans plus de détails, on peut d’abord noter que la différence « génétique » entre Sun, moteur d’innovation proche d’une entreprise de recherche, et Oracle, éditeur logiciel centré sur le business, augurait de nombreux chocs culturels.
Certains ont été violents, et la rupture a été amère. C’est le cas pour James Gosling, qui a été le plus prolixe (sur son blog) au sujet de son départ, évoquant une démission qui l’a occupé à plein temps pendant plusieurs semaines. De manière comparable, Tim Bray a rejoint Google, en ne détaillant pas les raisons qui l’ont poussées à quitter Oracle mais en laissant transparaître une certaine amertume.
D’autres sont partis car Oracle ne leur donnait pas de garanties sur leur technologie : Charles Nutter et Thomas Enebo ont rejoint Engine Yard pour continuer à développer JRuby. Kohsuke Kawaguchi a monté sa société pour porter Hudson.
Enfin, certains n’ont pas reçu d’offre d’Oracle. C’était attendu pour Jonathan Schwartz et Scott McNealy qui étaient quasiment condamnés par leur position au sommet de la hiérarchie de Sun. C’était plus surprenant pour Simon Phipps, responsable de l’open source, qui occupe un poste équivalent chez ForgeRock (qui entend développer -OpenSSO- pardon OpenAM, le nom OpenSSO étant déposé).
Alors, cette vague de départs sera t’elle préjudiciable à Oracle ? Sur le plan de l’innovation, certainement. Sur un plan purement business, on peut en douter, aucun des « sous »-produits (sans que nous portions de jugement de qualité) de Sun n’étant stratégiques pour la firme de Larry Ellison. D’ailleurs, si l’on jette rapidement un œil à ceux qui sont restés, on note John Fowler, Cindy Reese, et Mike Splain, tous trois impliqués dans la branche hardware. De là à dire que c’était la principale visée d’Oracle (avec la JVM)… « Malheureusement », Oracle a aussi hérité de bébés bien encombrants, comme les JUG (voir l’article de Nicolas de Loof à ce sujet).

Via infoWorld

Le coin de la technique

Nouvelle version pour EhCache

Terracotta maintient le rythme des évolutions Ehcache, en nous livrant cette nouvelle version numérotée 2.1.
Après un mois de maturation en bêta, l’éditeur officialise donc la dernière mouture stable de son célèbre cache.
C’est surtout l’occasion d’étoffer son offre produit en ajoutant notamment un plugin de monitoring permettant de surveiller en temps réel les métriques essentielles du cache. Grâce à lui, les développeurs pourront affiner la configuration du cache, par contre pour l’utiliser en production il vous faudra une version payante.
Le support Websphere a bénéficié lui aussi d’améliorations pour garantir à ses utilisateurs l’accès à toutes les fonctionnalités du produit.
Cela inclut tout naturellement, le support la solution Terracotta Web Session, un cluster de session web à haute disponibilité, déjà disponible pour Weblogic, JBoss, Tomcat et Jetty.
L’utilisation de JTA a aussi été largement améliorée, les configurations standalone et Hibernate sont à présent supportées, ce qui permet de couvrir l’intégralité des stratégies Hibernate.
En dernier point d’amélioration, le développement a été axé vers de meilleures performances et un paramétrage fin des SLAs. C’est par exemple la fonctionnalité NonStopCache qui permet de contrôler le timeout des opérations sur le cache, voire même de passer automatiquement d’un cache sur disque à un cache en mémoire vive en cas d’indisponibilité. Par ailleurs le UnlockedReadsView offre une vue non consistante du cache. Dans les faits, elle ignore les verrous d’écriture et ne pose pas de verrou de lecture, l’équivalent d’un READ_UNCOMITTED avec des performances très largement accrues.

• L’annonce Terracotta
• Un article plus poussé par Steve Harris
• La page d’accueil du projet

jucProfiler

Il y a quelques années, certains se sont arrachés les cheveux pour détecter les contentions dans un programme massivement parallélisé. Malheureusement pour les amoureux des nœuds au cerveau, les développeurs de chez IBM se sont penchés sur le sujet et proposent un outil pour diagnostiquer ce type de problèmes : jucProfiler (pour java.util.concurrent). Le principe est simple : instrumenter le bytecode de certaines classes de java.util.concurrent.locks et tracer les appels à java.util.concurrent.locks.LockSupport et java.util.concurrent.locks.AbstractQueuedSynchronizer.
L’outil génère ensuite un rapport permettant d’identifier deux types de problèmes sur les thread, consomateurs de temps :

• du temps de contention : un verrou est réservé par un autre thread.
• du temps d’attente : le thread est en wait.

Et cerise sur le gâteau, pour ceux d’entre vous lassés de devoir diagnostiquer des problèmes de performances en analysant des fichiers texte de trois pieds de long, un éditeur graphique est même fourni.

Comme le dit justement la conclusion de l’article, la généralisation de la programmation parallèle nous oblige à nous armer de meilleurs outils. Il semblerait que jucProfiler en fasse partie. Si l’un de nos lecteurs a eu l’opportunité de l’utiliser en condition réelle, nous sommes bien sûr preneurs d’un retour d’expérience.

Maven Enforcer

Sonatype a récemment mis en ligne une présentation en deux parties (ici et là) sur le plugin Maven Enforcer.
Ce plugin permet de définir des règles afin d’obtenir un build Maven reproductible sur différents environnements. Il permet entre autres :

• de spécifier une version ou une plage de versions de Maven,
• de spécifier une version ou une plage de versions du JDK,
• de spécifier une architecture (OS/CPU) sur laquelle s’exécute le build,
• de s’assurer que le projet ne contient pas de dépendances (transitives) vers des versions non explicites (SNAPSHOT, LATEST ou RELEASE),
• de s’assurer que le projet n’utilise pas de plugins ayant une version non explicite (SNAPSHOT, LATEST ou RELEASE),
• de bannir des dépendances,
• de définir ses propres règles (en Java ou avec un script BeanShell).

La présentation met l’accent sur la nécessité de fixer les versions des dépendances et des plugins afin d’éviter qu’un build ne devienne instable suite à la publication d’une nouvelle version d’une dépendance ou d’un plugin. Il préconise notamment l’emploi de Maven en version supérieure à 2.0.9 pour laquelle le POM parent n’utilise plus que des versions explicites des plugins.

Elle recommande aussi de spécifier une version du JDK (1.5.x par exemple) afin d’éviter différentes problématiques telles que l’utilisation d’API non supportées ou la différence de comportement de certains plugins Maven en fonction de la version de la JVM sur laquelle ils sont exécutés.

Une fois les bonnes pratiques exposées, la configuration des différentes règles permettant d’effectuer les vérifications est abordée.

Le plugin Maven Enforcer est encore peu connu mais gagnerait à être utilisé pour éviter des problèmes récurrents. Cette présentation est un bon point de départ pour aborder sa mise en place.

Cette formation approfondie de 4 jours vous permettra d’obtenir les compétences nécessaires pour optimiser la performance de vos applications Java. Vous aborderez pendant cette formation tous les aspects de la performance : l’outillage nécessaire, les méthodologies à appliquer, les concepts d’architecture sous jacents à la performance, les meilleures pratiques, le benchmarking et la gestion de mémoire.

A l’issue de cette formation, vous serez en mesure :

• D’identifier rapidement et régler les problèmes de performance de vos applications.
• D’identifier et résoudre des problèmes de fuite mémoire en quelques heures.
• D’isoler des problèmes classiques et d’éviter de s’engager dans des plans d’actions couteux et inefficaces.
• D’identifier des problèmes de performance avant qu’ils ne deviennent critiques pour les applications.

Les stagiaires bénéficieront des Tips de Kirk Pepperdine, référence reconnue dans le monde de l’optimisation de performance objet.
Kirk Pepperdine dispose de 15 ans d’expérience dans les technologies OO et l’optimisation de la performance. Figure emblématique du monde Java et élu « Champion JAVA » en 2005, Kirk est reconnu comme le référent de l’optimisation de performance Java.
Vous pouvez consulter le programme complet de cette formation en consultant notre site : http://training.xebia.fr/formation-java-performance-tuning-kirk-pepperdine/.

• Le catalogue numérique.
• Le catalogue PDF.

Xebia Training se positionne logiquement dans la continuité de Xebia, tant sur la qualité de son offre de formation technique que méthodologique (méthodes agiles), en proposant des formations haut de gamme animées uniquement par les référents de leur domaine.

Avec pour principe premier le refus de tout compromis sur la qualité du formateur et du contenu, Xebia Training fait systématiquement intervenir des acteurs de références dans leurs domaines respectifs.

Nos formations, savant équilibre entre théorie et travaux pratiques, sont destinées à un large public soucieux d’acquérir les meilleures pratiques de notre industrie.

Le premier XKE dans nos nouveaux locaux a donné lieu à de bien curieuses scènes : des bisounours ont hué des poubelles sous le regard moqueur de pokemons ! Et, non, les cartons de déménagement ne nous sont pas tombés sur la tête. Ce n'était là que quelques uns des noms choisis par des équipes de 3 à 4 consultants, qui se sont mesurés dans un concours de tuning de performance, sur une application Java EE standard, buggée (volontairement, pour une fois) par les maîtres de cérémonie, Guillaume Bodet et Cyrille Le Clerc. Tous les participants se sont vus remettre une VM, contenant un Tomcat, une application (PetClinic de Spring, revue et "corrigée") et des scripts de performance JMeter. Le code source n'a, dans un premier temps, pas été fourni.

Pour tous, un seul but : faire diminuer les temps de réponses de l'application.

Les règles étaient les suivantes :

• Un bug n'est considéré comme trouvé que lorsqu'il a été identifié, qu'un correctif a été proposé et que la preuve est faite que ce correctif permet d'améliorer significativement les temps de réponse.
• Il existe trois niveaux de difficulté, allant du bug évident à l'anomalie la plus fourbe.
• Le choix des outils est libre.

A vos marques... Prêts ? Débuggez !

Préambule

L'un des buts de ce Xke était d'être très didactique, dans les méthodes de recherche et dans l'utilisation des outils. Les bombes placées dans le code permettaient de réaliser une progression linéaire (dans la difficulté comme dans les gains attendus). Cette progression est retranscrite dans cet article et ceux qui vont suivre.

Cependant, pour différentes raisons que nous aurons l'occasion d'expliquer, l'ordre des analyses, et donc de découvertes des bugs, n'est pas celui qu'aurait choisi un champion de la performance, j'ai nommé Kirk Pepperdine. Nous lui avons soumis notre application, et nous vous exposerons sa méthode d'analyse et les raisons qui la motivent dans le dernier article de la série.

Premier contact avec l'application...

Ouverture du navigateur, entrée de l'url, et, pas de surprise, l'application PetClinic s'ouvre.

Premier lancement de JMeter, et première constatation : avec un seul utilisateur, l'application met en moyenne plus de 2 secondes à répondre. Inacceptable pour la plupart des sites web (surtout avec un seul utilisateur actif).

... et premiers réglages

A première vue, la machine ne semble pas à genoux, on peut donc incriminer directement l'application.
Nous allons donc chercher à savoir ce qu'elle fait. Un réflexe classique, qu'un certain nombre d'entre nous a eu, est d'aller ouvrir les logs. Catalina.out est vide, on n'a pas de répertoire de logs applicatives évident, à priori le coupable classique, la configuration log4j, est à écarter. Et pourtant... Pour savoir ce que fait réellement notre application, il est possible de réaliser une série de thread dumps. Pour cela, deux possibilités :

• la vieille école, qui va dumper le contenu des threads à l'aide d'un kill -3 sur la jvm.
• l'école moderne, qui va utiliser JVisualVm (et ses plugins) pour réaliser la même opération à l'aide d'une belle interface.

Et là, demie surprise, notre thread actif est souvent surpris dans la méthode org.apache.log4j.spi.LoggingEvent.getLocationInformation. Nous aurions donc un logger actif. Nos soupçons initiaux se confirment, ne reste plus qu'à débusquer le coupable.
Nous n'avons pas (encore) le code source. Or, cette bombe plombe tellement l'application qu'il n'est pas envisageable que nous ne puissions pas la résoudre de suite. On doit donc avoir un fichier de paramétrage de la log externalisé. Là encore, VisualVm va nous aider. Dans la fenêtre overview, les paramètres de démarrage de la VM sont affichés. Et l'on voit apparaitre une directive de configuration log4j, -Dlog4j.configuration.

Un petit grep dans le répertoire de lancement de Tomcat ($TOMCAT_HOME/bin), et nous voyons apparaître dans le setEnv.sh la ligne -Dlog4j.configuration=file:$CATALINA_HOME/conf/log.xml. Et si nous ouvrons ce fichier, le root Logger est bien en DEBUG. Mais aucune directive spécifique pour logger ailleurs que dans la console. Tout devrait donc aller dans catalina.out. Ca sent la redirection 'sauvage'. Continuons à parcourir les fichiers de lancement. Un petit tour dans catalina.sh, et surprise, une belle redirection Unix "$CATALINA_BASE"/logs/catalina.out 1> /var/log/catalina/tomcat.log &
Et en ouvrant ce fichier, on comprend mieux le temps perdu : des milliers de lignes de debug !

Celles ci ont d'ailleurs une particularité sympathique : à chaque ligne de debug, le numero de ligne de la classa Java est indiqué.
C'est pratique ! Pourquoi ne met on pas systématiquement en place cette configuration sur nos projets ?
Un petit tour dans la documentation Log4J nous apprend :

Log4J nous prévient, ces méthodes sont sous performantes. Si l'on creuse un peu dans le source, on trouve la classe affichant les pattern %M et %L, org.apache.log4j.spi.LocationInfo, qui contient le constructeur suivant :

Autrement dit, pour chaque ligne de log, Log4J génère une stackTrace pour pouvoir récupérer le numéro de la ligne et le nom de la méthode. Pas vraiment performant.
Modifions donc le pattern et observons le résultat.

• Suppression de %M:%L dans le pattern du Logger
• Temps moyen de 2,3 s à 2,0 s pour 1 utilisateur
• 2 points pour l'équipe qui a trouvé

Toujours concernant ce fichier de log, nous voyons apparaître une ligne ne respectant pas le PatternLayout de Log4J, préfixée par Hibernate, qui trace une requête SQL. Gardons cette ligne en mémoire, nous y repenserons quand nous aurons le code source.

Deuxième amélioration immédiate envisageable, une application, qui plus est en production, ne devrait pas avoir besoin d'un niveau de log aussi fin. Passons le donc à ERROR.

• Logger de DEBUG à ERROR
• Temps moyen de 2,0 s à 1,75 s pour 1 utilisateur
• 1 point pour l'équipe qui a trouvé

Nous avons fait un sort au logger. Mais nous n'en avons pas encore fini avec la configuration out-of-the-box de cette application.

Source

Image libre de droits