Duchess France
A Duchess Community Blog for France

Devoxx est une conférence européenne indépendante qui porte sur les technologies Java/JVM . Organisée en Belgique, à Anvers, elle nous permettra d’entendre du 15 au 19 novembre 2010 des speakers de haut niveau. Un peu moins de 3000 développeurs venant de plus de 40 pays différents s’y retrouvent chaque année.

Les conférences

Les University Days.

Les 2 premiers jours sont appelés les University Days. On y retrouve principalement des ‘University Talks’, des conférences de 3 heures qui abordent un sujet en profondeur. Il y a à chaque fois plusieurs conférences sur un même créneau horaire. Les sujets sont variés, la plupart sont techniques. Ainsi, on retrouve des sujets :

• sur le langage comme Java EE6 par Antonio Goncalves et Alexis Moussine-Pouchkine ou What’s new in Hibernate – a JPA 2 perspective par Emmanuel Bernard
• autour de tout ce qui est Desktop/Mobile comme Dive into Android de Romain Guy
• sur d’autres langages tournant sur la JVM (Groovy,Scala) comme Groovy/Gaelyk/GAE de Guillaume Laforge
• sur le Cloud/NoSQL
• également des sujets sur la méthodologie (Productive Programmer).

Chacun peut participer à 2 sessions de 3 heures par jour, une le matin et l’autre en début d’après midi. Ensuite, place aux ‘Tools in action’. Ce sont des petites sessions de 30 minutes qui permettent aux speakers de nous faire découvrir un outil auquel ils ont participé. Les sujets sont variés, d’une présentation de spring developer tools (que j’apprécie énormément au quotidien), à visual VM (outil de monitoring) en passant par Apache Mahout.
Entre 19 et 22h, ont lieu des BOF (Bird-of-a-Feather) qui diffèrent beaucoup de tous les autres types de conférences.
Elles réunissent peu de personnes et sont beaucoup plus informelles. Elles sont généralement menées par un ou deux speakers de manière libre. Parfois, il y a une brève présentation puis des questions, parfois ce sont des discussions ouvertes sur un sujet précis. Actuellement, le planning n’est pas finalisé sur les BOFs.

Les Conference Days

Pour les 3 jours suivants, du mercredi au vendredi, le format diffère. Les conférences  ne sont plus de 3 heures mais d’une heure : cela permet de voir bien plus de sujets différents mais de manière un peu plus superficielle. Les sujets là encore tournent autour des mêmes thèmes dans 5 salles différentes. Les sessions ‘Tools in action’ disparaissent au profit des Quickies, qui durent 15 minutes pendant la pause déjeuner.

Duchess à Devoxx

Les duchess seront présentes toute la semaine à Devoxx et plusieurs nationalités seront présentes (France, Belgique, Hollande …). Le jeudi soir, les Duchess organiseront une BoF pour discuter en petits groupes (6) autour de sujets choisis sur le thème ‘Les femmes dans l’informatique‘.

Ce que j’aime à Devoxx

Pour un prix raisonnable, Devoxx apparait comme un des principaux rendez-vous européen. Les speakers y sont accessibles et l’organisation bien rodée. En une semaine, cela permet d’améliorer fortement sa ‘culture générale Java’, surtout si l’on est débutant. Anvers n’est qu’à deux heures de Paris en Thalys, les hôtels y sont à un prix abordable. Bref, pour un investissement moyen, cela permet vraiment de progresser au niveau technique et de rencontrer énormément de monde, ce qui est toujours un avantage. Certaines SSII l’ont bien compris et y envoient chaque année plusieurs consultants.  Ceux qui n’ont pas une entreprise pour les y envoyer peuvent tout à fait se le permettre au niveau financier. Les conférences sont bien sûr des endroits où l’on apprend beaucoup, mais toutes les discussions ‘off’ pendant la pause déjeuner ou autour d’une bière le soir permettent d’avoir des retours d’expérience très intéressants.

Infos Pratiques

Au niveau de la gestion à proprement parler, pour ceux qui assiste aux University Days, deux possibilités : soit dormir sur place le dimanche soir, soit il est tout à fait possible de prendre l’un des premiers Thalys, de passer à l’hôtel si celui ci est proche de la gare et en ne perdant pas de temps de prendre le tramway pour assister aux premières sessions.
Pour les hôtels, les français semblent se regrouper cette année à deux endroits différents : l’Agora (qui devient à partir d’octobre le ‘all seasons Antwerpen City Center’) et le Park Inn qui sont tous les deux placés juste à côté de la gare. Il vaut mieux éviter de prendre les hôtels qui semblent plus proche de la salle pour deux raisons : ils sont mal desservis en transport en commun et cela veut dire également que vous ferez le chemin seul le soir et le matin.
L’année dernière, le petit déjeuner était compris dans la conférence, tout comme le repas du midi.
Au niveau du train du retour pour le vendredi, beaucoup prennent les thalys de 14h30 ou de 15h30, et certains y restent le week end pour découvrir la Belgique !

Cet article est un retour d’expérience sur la mise en place d’une pagination dans un écran de recherche contenant un filtre composé de deux listes déroulantes. Hibernate fonctionne avec la majorité des SGBD. Toutefois, ceux-ci n’offrent pas tous les mêmes fonctionnalités. Le SQL natif généré par Hibernate sera différent selon les SGBD. Nous verrons en quoi cela peut poser problème.

Ce cas s’appuie sur une application utilisant Hibernate et Sybase ASE 12.5. L’écran à développer, en plus de la pagination, possède un filtre facultatif. La clause where étant dynamique, je décide d’utiliser les Criteria pour écrire ma requête.  Il y a dans le manuel Hibernate une section dédiée à la pagination. Elle vous conseille d’utiliser les méthodes setFirstResult et setMaxResults de l’interface Query en précisant qu’Hibernate sait comment traduire ceci en SQL natif adapté à votre SGBD.

J’implémente ma dao et je filtre le résultat renvoyé :

Criteria crit = session.createCriteria(Flux.class);
//ajout des restrictions – filtre utilisateur
List result = crit.setFirstResult(firstResult)
            .setMaxResults(nbRows).list();

J’écris mon test unitaire, je réalise quelques tests sur ma base de données de test, je « commit ». Voilà, c’est fini !

Quelque temps plus tard, le chef de projet souhaite faire des tests en pré-qualification sur un nombre de lignes conséquent (il est vrai que tester la pagination quand il n’y a qu’une seule page ce n’est pas très drôle). La pagination fonctionne sur les premières pages, mais impossible d’afficher la dernière page sans faire tomber l’application. Le message d’erreur suivant est très explicite :

<10 juin 2010 15 h 20 CEST> <Critical> <Health> <BEA-310003>
<Free memory in the server is 4 122 880 bytes. There is danger of OutOfMemoryError>
Exception in thread "[ACTIVE] ExecuteThread: '18' for queue: 'weblogic.kernel.
Default (self-tuning)'" java.lang.OutOfMemoryError: Java heap space

...
The exception message is - Java heap space
java.lang.OutOfMemoryError: Java heap space

En regardant le code SQL généré par Hibernate, on remarque qu’il n’y a pas de filtre pour la pagination. Malheureusement, Sybase possède moins de fonctionnalités que d’autres SGBD et ne connaît pas les mots clef « LIMIT » ou « ROWID » et de ce fait, le setFirstResult et setMaxResults ne sont pas traduits en SQL natif. Hibernate est donc obligé de tout récupérer dans sa requête et de faire le filtre de pagination côté java. Il charge les objets en mémoire tant qu’il n’a pas les résultats souhaités pour la page demandée. Cela ne pose pas de problème pour les premières pages, mais lorsqu’on veut atteindre la dernière page, la consommation mémoire explose.

Figure 1 – Utilisation de la mémoire – schéma de JConsole

Ainsi, nous ne pouvons pas utiliser l’interface Query dans ce cas. Cette version de Sybase ne supporte pas non plus les sous requêtes ordonnées. La seule solution que nous avons trouvée est de faire la  requête en deux temps : d’abord sur les identifiants, puis récupérer les données  à partir de ceux-ci.

Cette solution peut s’implémenter de deux façons :

• Solution 1 : récupérer la liste des identifiants filtrées par Hibernate (même code qu’au début, mais en ne retournant que les identifiants) ;
• Solution 2 : obtenir la liste de tous les identifiants, puis la filtrer en utilisant la méthode subList de l’interface List.

Nous avons testé les deux solutions. En observant l’utilisation de la mémoire, la solution 2 semble plus performante.

Figure 2 – utilisation de la mémoire pour la solution 1

Figure 3 – utilisation de la mémoire pour la solution 2

Pour finir, on a une première requête écrite avec les Criteria qui permet de récupérer tous les identifiants en fonction des filtres de l’utilisateur. Puis, on crée une sous-liste pour ne garder que les id correspondant à la page demandée. On fait une dernière requête en HQL pour récupérer les objets.

Criteria crit = session.createCriteria(Flux.class);
//ajout des restrictions – filtre utilisateur

List lsId = crit.setProjection(
           Projections.property("id")).list() ;

List result = null;

if ( lsId != null &&  lsId.size()>0) {
	//si la liste d'id est vide, la requête hql plante
	Query q = getSessionFactory().getCurrentSession().getNamedQuery(
      		"getListFluxByIds").setParameterList(
	      "idList",
	      lsId.subList(firstResult,
	      lastResult));

	result = (List) q.list();
}

A retenir :

Hibernate est votre ami, mais il ne peut pas être plus fort que votre SGBD. Il est donc utile de vérifier le code SQL natif qu’il génère.

Concernant Syabse ASE 12.5, on espère que les versions futures supporteront les fonctions liées à la pagination.

Je remercie David, Ellène et Victor pour la relecture et les conseils sur WordPress.

Cette soirée fut drôlement riche en évènement et en surprise … Ne dévoilons pas tout et commençons par la première partie de soirée : l’AvantJUG.

L’AvantJUG

Pas mal de Duchess sont présentes, certaines accompagnées de leur collègue, et quelques nouvelles qui assistent pour la première fois à l’AvantJUG. Nicolas Martignole auteur de l’incontournable blog Le Touilleur Express a assisté à l’AvantJUG en tant qu’observateur pour voir comment se passait notre première partie de soirée.

Dans les conversations, on pouvait entendre qu’il y a un iPad à gagner ce soir ! En plus des bières promis par les organisateurs du ParisJUG pour tout ce qui arrivaient les cheveux bleus, cela promet d’être une belle soirée . D’ailleurs en parlant de cheveux bleus, certaines d’entre nous ont profité des bombes à laques bleus amenées par Laure pour réaliser une petite séance de coiffure improvisée.

Déjà 19h ? On se prépare et en route pour l’ISEP !

Avant de commencer la soirée …

Antonio prend la parole pour faire le point sur les JUG et Oracle. Après quelques mois de silence, Oracle s’est enfin prononcé sur leurs intentions par rapport au JUG. Ils ont décidé de mettre en place 3 catégories de JUG :

• les gros JUG avec plus de 1000 membres et un cadre juridique pour qui Oracle sortira le tapis rouge avec soutien en force,
• les JUG de taille moyenne qu’Oracle soutiendra … moralement on va dire,
• et les JUG virtuels qui auront droit à une petite tape dans le dos avec un “C’est sympa ce que vous faîtes”.

Le petit souci du ParisJUG, c’est que nous sommes 200 à nous réunir chaque mois et un millier sur la mailing list mais juridiquement il est composé de trois membres ! Alors comment Oracle les considèrera ?

La présentation débute maintenant …

L’optimisation des performances : pas si effrayant que ça !

Holly Cummins commence tout d’abord par nous remercier pour l’accueil en français s’il vous plaît !

Elle poursuit ensuite par une présentation de son parcours au travers de sa couleur de cheveux.

• En 2001, les cheveux roses, elle arrive chez IBM pour travailler sur Websphere.
• En 2004, pour se rapprocher des couleurs d’IBM, elle choisit le bleu et au même moment elle commence à travailler sur les performances de la JVM.
• Actuellement, avec les cheveux tout simplement noir, elle contribue au projet open source Apache Aries.

Les performances ce n’est pas si terrible que ça ! Holly souhaite dédramatiser la situation.

Une application répondant mal, ce n’est pas seulement problématique mais aussi coûteux :

• en électricité : cela consomme beaucoup surtout quand on a des data centers comme Google,
• les employés utilisant ces applications sont moins productifs,
• une perte de business à cause de pages qui ne répondent pas assez vite voire même pas du tout.

La loi de Moore prédit que l’on aura des processeurs de plus en plus rapides mais les SI peuvent ils se permettre de changer de matériels régulièrement pour améliorer leur performance ? Le problème c’est surtout qu’on a atteint le maximum de la scalabilité verticale. On ne peut pas faire tourner les processeurs plus vite pour une question de dissipation de chaleur. Par ailleurs, à l’heure actuelle c’est l’accès aux données en mémoire qui limite les vitesses de processeurs. On fait de la scalabilité horizontale c’est à dire qu’on augmente le nombre de core. Mais cette technique impose de réaliser des tâches en parallèle et pose donc plus de problème de synchronisation.

A son arrivée chez IBM, connaissant peu de choses sur les performances, selon ses termes, elle a cherché quelques livres pour l’aider. Et malheureusement dans la monstrueuse bibliothèque d’IBM seuls deux livres traitaient de la performance !

Méthodologie

Les performances sont limitées par les ressources. Il faut donc trouver le goulet d’étranglement et régler le problème. Un exercice qui n’est pas toujours facile à appliquer en général. Voici quelques ressources à considérer : le CPU, les accès mémoire, l’espace mémoire, les accès disques …
Il faut comprendre comment la JVM fonctionne afin de trouver le problème. Il est indispensable également de se faire aider d’outils qui fourniront des mesures et permettront de détecter ce goulet d’étranglement.

Les outils de performance d’IBM

IBM fournit un certain nombre d’outils permettant de mesurer et détecter plus facilement les goulets d’étranglement. Ils sont disponibles gratuitement sur le site IBM Assistant. Mais attention ces outils fonctionnent majoritairement sur les JVM d’IBM.

Détecter les problèmes liés à la mémoire

La mémoire est une ressource critique car elle ne peut pas être dimensionnée à l’infini. Elle est d’abord limitée par la mémoire physiquement disponible. Ensuite, il est souvent nécessaire de faire un compromis entre la quantité de mémoire et le temps que prendront les phases de Garbage Collection.
Pour identifier les problèmes de mémoire, deux types d’outils sont possibles : les traces de l’activité du GC et l’inspection du contenu de la heap (un heap dump).
Activer l’option -verbose:gc sur la JVM permet de tracer les executions du Garbage Collector et d’identifier des fréquences ou des volumes anormaux. L’outil GC and Memory Visualizer permet d’exploiter ces traces et de les représenter visuellement. Cette technique permet de voir quand la mémoire est sur-utilisé et de constater une fuite mémoire mais pas de savoir par quel type d’objets.
Pour cela il est nécessaire de réaliser un heap dump.
Pour visualiser les fuites mémoire, voici deux outils qu’elle nous conseille :

• Health Center est un outil d’IBM permettant de réaliser le diagnostic et le monitoring des applications Java. Il permet de visualiser les classes utilisées, l’utilisation de la mémoire, les entrées/sorties …

• Memory Analyzer (MAT)  pour visualiser les appels aux objets et la mémoire prise par ces objets.

Dans la démo, Holly nous montre un exemple d’utilisation de ces outils. Il y a un trop grand nombre de String, ainsi qu’un très grand nombre d’entrées de Map. Le souci dans cette application est que des chaînes sont générées dynamiquement pour chaque utilisation d’un label de produit.

La mémoire native

On appelle mémoire native la mémoire utilisée par le core de la JVM pour gérer les processus natifs de la JVM (gestion des threads, gestion de la mémoire, gestion de la pile d’appel). Cette mémoire est distincte de la Heap qui est la zone dans laquelle les objets manipulés par les applications sont créés. Il arrive que les fuites se produisent dans la mémoire native parce qu’elles sont causées par des processus natifs de la JVM. Or cette mémoire n’est pas traitée par les outils dont on vient de parler. Il faut utiliser les outils de l’OS perfmon sous Windows et ps sous Linux pour surveiller la mémoire totale du process JVM pour identifier une dérive.

Détecter les problèmes liés au CPU

Tout d’abord, les problèmes de CPU sont souvent en réalité des problèmes de mémoire. Le GC cause beaucoup d’opérations sans entrées sorties et donc génère souvent de fortes consommations CPU. Les problèmes liés au CPU sont en général du code invoqué plus que nécessaire. Pour détecter ces problèmes, deux méthodes existent :

• méthode de tracing : pour savoir dans quels méthodes passent notre application et trouver la méthode nous posant problème,
• méthode de profiling : pour cela, il nous faut un outil de profiling comme Health Center par exemple.

Paradoxalement, une utilisation très basse de la CPU peut indiquer également un problème parce que dans ce cas ce sont des attentes qui dégradent les temps de réponse. Le système qui attend des entrées/sorties ne consomme pas de CPU.

Détecter les problèmes liés aux entrées/sorties

Il existe deux causes de problèmes d’entrées/sorties : les accès disque et les appels réseau.
Les accès disques peuvent ralentir le service si le disque n’arrive pas à traiter les demandes suffisamment vite. Cela peut arriver pour une application fortement consommatrice d’écriture (via les logs par exemple). Mais la gestion des swaps mémoire peut également causer une sur-utilisation des disques pour des process s’allouant de grandes quantités de mémoire.
L’autre source de dégradation par entrées/sorties est causée par les requêtes aux SGBD ou avec des services en backend.
Le problème n’est pas évident à détecter. Il faut utiliser les outils du système en conjonction avec les outils de profiling pour enquêter et trouver le problème.

Synchronization : la concurrence et la performance

Holly avoue que les problèmes d’accès concurrents ne sont pas faciles à résoudre. La nécessité de conserver la cohérence entre les actions des différents threads impose d’utiliser une forme de verrou (les synchronized) qui limitent les performances sous forte concurrence. Il faut donc les réduire au maximum.

L’évolution des processeurs ces derniers temps se fait par scalabilité horizontale et implique que l’on ne peut plus gagner en performance simplement en ayant des processeurs qui vont plus vite. Pour utiliser au mieux les multi-cores, il faut savoir paralléliser les tâches, ce qui nécessite de trouver un bon compromis entre synchronisation des données et augmentation du débit.

Fin de la première partie, nous passons au buffet.

Le buffet

Mais avant une petite photo groupée autour de Holly Cummins de tout ce qui ont eu le courage de venir les cheveux colorés. Le buffet fut sponsorisé par Octo. Pour cette soirée des représentants du BreizhJUG, NormandyJUG et le BruJUG sont présents.

Les textes et les photos sont Claude Falguière et d’Ellène Dijoux.

Ce mois-ci performances et OSGi sont au menu de la soirée du ParisJUG. Avec Holly Cummins notre speaker du mois, venez découvrir les deux thèmes qu’elle abordera ce soir :

Optimisation de performances

Mémoire, threads ? Tous ces concepts paraissent très mystérieux. En fait ce sont des comportements très simples dès lors qu’ils sont expliqués et aussi quand on peut les visualiser. Les outils fournis avec la Java 5 ainsi que des outils plus spécifiques permettent de visualiser les différentes zones de la mémoire, les données liées à chaque exécution du GC, le code en cours d’exécution pour chaque thread. Ces outils aident à comprendre comment une application sollicite les différentes zones de la mémoire. Certains OutOfMemory sont réfractaires aux modifications de -Xms -Xmx les paramètres qui dimensionnent la heap. C’est simplement parce que la heap ne concerne que les objets crées par l’application. D’autres zones mémoire sont utilisées pour stocker les classes, la pile d’appel. Même la heap est composée de plusieurs zones dans une JVM générationnelle.
Beaucoup de consommation CPU, l’application pause tout le temps car la JMV passe beaucoup de temps dans des GC ? L’analyse détaillée des données de GC permet de comprendre pourquoi des GC sont fréquents, quelle est la durée de vie des objets impliqués et d’avoir de premières pistes pour identifier  une consommation mémoire excessive ou s’adapter à un usage particulier.Ou alors, les réponses sont parfois lentes sans raison apparente. Ces outils aident à identifier si un thread est en train d’en bloquer un autre parce qu’ils nécessitent tous les deux l’accès à une variable protégé par un synchronized. Même si la JVM nous décharge de la gestion des allocations/dé-allocations mémoire et du multi-threading, il est utile de comprendre comment ces mécanismes marchent pour les utiliser de manière efficace en Java.

OSGi

On parle de la spécification OSGi mais savez vous de quoi il s’agit ? OSGi est une spécification ayant pour but de définir des applications modulaires, portables et dynamiques. Pour faire simple cela permet de réaliser des installations de modules à chaud sans redémarrage de la JVM. Le plus bel exemple que l’on a sans doute tous sous les yeux est Eclipse et son système de plugins par exemple qui respecte la spécification OSGi. Elle existe donc depuis un moment déjà mais revient au goût du jour pour tenter de répondre à nos problèmes de modularité sur nos applications web. Une présentation d’OSGi a été réalisée au ParisJUG en Octobre 2008 par Cyrille Leclerc et Nicolas Griso pour présenter ce que OSGi pouvait nous apporter. Depuis plus d’un an s’est écoulé, Holly Cummins va nous présenter au travers du projet open source sur lequel elle travaille Apache Aries, les enjeux d’un tel outil. Injection de dépendances, transaction et persistance : venez découvrir comment l’on peut répondre à ces problématiques avec OSGi.

Les textes sont d’Ellène Dijoux et Claude Falguière.