Blog Xebia France » JVM

Legacy code – gestion des exceptions avec JPDA

Nabil Gasri — Mon, 12 Dec 2011 13:22:00 +0000

Il y a quelques jours un ami a sollicité mon aide pour résoudre un problème peu commun. Il avait comme tâche de lever des alertes sur les exceptions levées par une application dont il ne peut modifier le code. L’application utilise mal l’API de log et ne loggue pas (toutes) les exceptions. De plus, elle est peu documentée et le peu qui existe est obsolète.

A chaque exception qui survient pendant l’exécution de l’application, il doit envoyer un mail d’alerte.

L’application est un programme JAVA standalone lancé via un script shell. Ci après les solutions auxquelles j’ai pensé :

Utiliser JPDA (Java Platform Debugger Architecture).
Utiliser l’api instrumentation de Java.
Utiliser de l’AOP.

Je vous propose dans cette série de trois articles de développer chacune de ces solutions.

Dans cette première partie, je vais explorer JPDA. Je commencerais par une brève introduction, avant de présenter la résolution du problème.

JPDA

Java Platform Debugger Architecture (JPDA) est un ensemble d’API créé dans le but de permettre de déboguer des programmes JAVA. Elle définit le cadre dans lequel un développeur débogue une JVM en utilisant un outil de débogage. Le débogueur crée des points d’arrêt. La JVM débogguée arrête son exécution lors de la rencontre d’un point d’arrêt et notifie le déboggeur. JPDA peut être considérée comme une sorte de communication inter-processus. En effet, elle permet à deux JMV (déboguée et débogueur) d’échanger des informations. Plus, il permet à la JVM source (celle du débogueur) de commander et contrôler l’exécution de la JVM cible (déboguée).

Cette architecture repose sur deux API et un protocole :

Java Virtual Machine Tools Interface (JVMTI) : une API native que la JVM doit implémenter pour fournir ledit « mode débug ». Elle est utilisée aussi par les éditeurs voulant créer des outils de débogage, profiling ou monitoring. Introduite depuis JavaSE 5.0, elle remplace Java Virtual Machine Debug Interface (JVMDI) et Java Virtual Machine Profiler Interface (JVMPI).
Le protocole Java Debug Wire Protocol (JDWP) : un protocole binaire qui formalise les échanges entre le programme débogueur et le programme débogué.
Java Debug Interface (JDI) : API de haut niveau écrite en Java, à utiliser par l’outil de débogage. Les IDE comme Eclipse et IntelliJ IDEA utilisent cette API.

Pour notre problème, c’est l’API JDI qui nous intéresse. En effet, nous allons l’utiliser pour créer notre débogueur.

Voici le code que nous allons déboguer :

package fr.xebia.jpda;
public class LegacyCode {
    public static void main(String[] args) {
        try {
   throw new RuntimeException("Test of a caughted exception");  
 } catch (Exception ex) {
  ex.printStackTrace();
  throw new IllegalStateException("Test of an uncaughted exception",ex);
 }
   } 
}

Le seul but de ce bout de code est de simuler un programme qui lance de temps en temps des exceptions qu’il catche et traite, et d’autres qu’il ne catche pas.

La solution consiste à attacher cette JVM à un débogueur que nous allons créer. Le débogueur crée un point d’arrêt sur toutes les exceptions lancées (comme vous le faites sur votre IDE préféré).

Le débogueur est alors notifié sur les exceptions. Pour chaque exception, le débogueur demandera à la JVM cible d’écrire la stacktrace dans un fichier qui pourra être envoyé par mail.

Connexion à la JVM

Les échanges d’information entre les JVM se basent sur le protocole JDWP. Ce protocole présente deux types de transport:

le transport par socket: permet de déboguer une JVM à distance. La JVM cible peut être sur la même machine que le débogueur comme elle peut être sur une autre machine. Lors du lancement de la JVM cible il faut spécifier le port du débogage.
le transport par mémoire partagée: permet de déboguer une JVM locale en connaissant son ID.

Pour pouvoir établir une connexion entre les deux JVM, ,il faut que la machine virtuelle à déboguer soit lancée en mode Debug.

Pour ça, il faut rajouter une des lignes suivantes au script de démarrage de la JVM cible:

-Xdebug -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n : mise en place d’un connecteur de type socket qui écoute sur le port 8000
-agentlib:jdwp:transport=dt_socket,address=8000,server=y,suspend=n à partir de JavaSe 5 (la première manière est toujours utilisée)
-Xdebug -Xrunjdwp:transport=dt_shmem,server=y,suspend=y : mise en place d’un connecteur de type mémoire partagée (il faut alors connaitre le PID du processus cible).
-Xagentlib:transport=dt_shmem,server=y,suspend=y.

La connexion à la JVM cible se fait comme suit:

public static VirtualMachine connect(String port) throws IOException, IllegalConnectorArgumentsException {
        AttachingConnector connector = null;
        VirtualMachineManager vmManager = Bootstrap.virtualMachineManager();
        for (Connector aconnector : vmManager.allConnectors()) {
            if ("com.sun.jdi.SocketAttach".equals(aconnector.name())) {
  connector = (AttachingConnector) aconnector;
  break;
     }
 }
 Map args = connector.defaultArguments();
        Connector.Argument pidArgument = args.get("port");
        pidArgument.setValue(port);
        return connector.attach(args);
 }

Cette méthode prend en argument le numéro de port du débogue de la JVM cible (je suppose que les deux JVM tournent sur la même machine).

Elle retourne un Objet VirtualMachine qui référence la JVM cible, ou plutôt un miroir (Mirror) de la JVM cible.

Création du point d’arrêt

Une fois nous avons attaché la JVM cible, nous allons créer un point d’arrêt. Celui ci est lié à la levée des exceptions « catchées » et « non catchées ». Nous supposons que nous voulons être alertés pour toutes les exceptions.

public static void createExceptionBreakPoint(VirtualMachine vm) {
        EventRequestManager erm = vm.eventRequestManager();
        List referenceTypes = vm.classesByName("java.lang.Throwable");
        for (ReferenceType refType : referenceTypes){
  ExceptionRequest exceptionRequest = erm.createExceptionRequest(refType, true, true);
  exceptionRequest.setEnabled(true);
 }
}

Traitement des Exceptions

Maintenant que le point d’arrêt est créé et activé, nous pouvons commencer le traitement des notifications de débogage. Ceci se fait dans une boucle. Nous nous intéressons uniquement aux événements de type ExceptionEvent.

Notre idée principale est de faire en sorte que l’exception catchée soit loguée dans un fichier particulier. On peut penser à utiliser printStackTrace(PrintStream ps) ou printStackTrace(PrintWriter pw). Mais dans le programme débogueur nous n’avons qu’une image « miroir » de la vraie exception lancée dans la JVM cible. Nous pouvons alors faire une invocation distante de la méthode. Ces méthodes prennent en argument chacune un objet. Ceci dit, il nous faut disposer de cet objet dans la JVM cible. Heureusement, il nous est possible de créer des objets dans la JVM cible avec JDI.

Donc si nous considérons l’utilisation de printStackTrace(PrintStream ps), nous commençons par créer une chaine de caractère représentant le nom de fichier où nous voulons loguer l’exception, avant de créer un objet PrintStream. Enfin nous allons invoquer la méthode printStackTrace(PrintStream ps) sur l’exception catchée.

Une fois l’exception loguée, nous pouvant envoyer ce fichier comme pièce jointe d’un mail (l’envoi ne fait pas partie de l’exemple ci-dessous). Dans cet exemple nous nous contentons d’afficher son contenu.

public static void handleExceptionEvent(ExceptionEvent exceptionEvent) throws Exception {
        ObjectReference remoteException = exceptionEvent.exception();
        ThreadReference thread = exceptionEvent.thread();
        List paramList = new ArrayList(1);
        paramList.add(dumpFileName);
        //crer un printStream dans la JVM cible
        ObjectReference printStreamRef = printStreamClassType.newInstance(thread, printStreamConstructor, paramList,
                ObjectReference.INVOKE_SINGLE_THREADED);
        ReferenceType remoteType = remoteException.referenceType();
        Method printStackTrace = (Method) remoteType.methodsByName("printStackTrace").get(1);
        paramList.clear();
        paramList.add(printStreamRef);
        remoteException.invokeMethod(thread, printStackTrace, paramList, ObjectReference.INVOKE_SINGLE_THREADED);
        Scanner scanner = new Scanner(new File(dumpFileName.value()));
        while (scanner.hasNextLine()){
  System.out.println(scanner.nextLine());
 }
}

Conclusion

JPDA reste une API peu connue des développeurs Java et ceci malgré les possibilités qu’elle offre au programmeur. On peut lui reprocher l’overhead – dû surtout à la communication inter-processus – qu’elle induit dans l’application. Outre la complexité de son utilisation, beaucoup d’instructions doivent être écrites pour accomplir une « simple » tâche. Dans le prochain article nous verrons comment accomplir la même chose en utilisant l’API Instrumentation de Java.

Revue de Presse Xebia

Xebia France — Tue, 24 May 2011 05:59:00 +0000

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

Actualité éditeurs / SSII

Le coin de la technique

JUnitParams, un framework pour paramétrer vos méthodes de test

Actualité éditeurs / SSII

La VM d’Oracle JRockit devient gratuite

Henrik Ståhl, chef de projet du produit, l’a annoncé sur son blog: JRockit devient gratuite. Cette JVM, alternative payante à celle de Sun, fut longtemps propriété de BEA avant son rachat par Oracle. Il y a peu de temps, Oracle proposait encore commercialement ce produit, présenté par exemple dans ce document commercial.
JRockit est donc maintenant gratuit, mais on peut noter les point suivant:

gratuit et non pas libre.
les fonctions Temps Réel (permettant de limiter la durée des pauses dues au GC ), VirtualEdition (faisant tourner nativement JRockit dans une machine virtuelle, sans OS hôte) et l’outil JRockit Mission Control (console de management, monitoring et profiling) restent payants.
comme le rappelle Emmanuel Lecharny sur le Google Group des Cast Codeurs, les conditions d’utilisation sont floues concernant l’utilisation sur des serveur ou la redistribution.

En fait, ce passage au gratuit permettra sans doutes à Oracle d’augmenter le nombre d’utilisateurs de JRockit et de fluidifier les ajouts de fonctionnalités de ce dernier dans OpenJDK. Il se dit depuis longtemps qu’Oracle désire disposer à terme d’une unique base de JVM unifiant le meilleur des mondes des VM Sun et JRockit. Les coûts de maintenance seront diminués alors que le le marché des personnes susceptibles de payer pour les outils ou services additionnels s’élargira.

Concrètement, que cela change t’il ? Nous pouvons tester JRockit. Bien. Dans certains cas d’utilisation vous noterez une différence par rapport à votre JVM habituelle. Mais avant de vous précipiter, êtes vous sûr d’avoir commencé par analyser les problèmes venant de votre propre code ? Il y a fort à parier que vous résolverez plus en l’étudiant qu’en changeant de JVM

Terracotta racheté par Software AG

Ari Zilka, son fondateur et CTO, annonce que Terracotta vient d’être racheté par Software AG, un gros du logiciel allemand. Pour mémoire Terracotta avait à l’origine sa propre solution (décrite en détails chez InfoQ) de clustering, puis avait racheté EhCache et enfin Quartz avant de sortir Big Memory.

L’annonce est assez convenue: tout le monde doit y trouver son compte, que ce soit la communauté Open Source, les clients actuels et futurs ainsi que toute l’industrie Java. Bref, tout va bien dans le meilleur des mondes. Comme nous l’annoncions à l’époque du rachat d’EhCache, Terracotta souhaitait se faire racheter. Il aura fallu attendre près de 2 ans, mais Terracotta dispose maintenant d’un nouvel atout pour faire connaître ses solutions et vendre ses services tout en les intégrant avec les produits de Software AG. En effet, les solutions Paas et de Cloud de Softawre AG doivent s’appuyer sur les outils de Terracotta.

Il sera intéressant de voir maintenant le positionnement exact de ce nouveau couple concernant les offres Paas par rapport à VMWare d’une part et à l’offre de SAP concernant le BI à la demande d’autre part. James Governor nous résume assez bien la situation dans cet article.

Le coin de la technique

JUnitParams, un framework pour paramétrer vos méthodes de test

Je suis pratiquement sûr que tous, vous avez déjà écrit une classe de test comme celle-ci :

public class MyFibonnacciTest {
  @Resource
  private Fibonnacci fibonnacci;
  @Test
  public void should_return_2_when_inputs_are_1_and_1() {
    // Given:
    int i = 1;
    int j = 1;
    // When:
    int k = fibonnacci.computeNext(i, j);
    // Then:
    assertThat(k, equalTo(2));
  }
  @Test
  public void should_return_3_when_inputs_are_1_and_2() {
    // Given:
    int i = 1;
    int j = 2;
    // When:
    int k = fibonnacci.computeNext(i, j);
    // Then:
    assertThat(k, equalTo(3));
  }
  // ...
}

C’est très pratique pour la lisibilité: à la lecture des noms de méthodes, vous savez ce qui est testé. Par contre, il est clair que chaque méthode varie très peu. C’est là que vous sortez le logiciel JUnitParams de votre boite à outils.

Il vous permet de n’écrire qu’une seule fois la méthode et d’y ajouter, en annotation, vos jeux de données de trois manières différentes:

simplement en listant les jeux de données. C’est pratique lorsque les données sont simples et qu’il n’y a pas trop de cas:

public class MyFibonnacciTest {
  @Resource
  private Fibonnacci fibonnacci;
  @Test
  @Parameters({"1, 1, 2",
               "1, 2, 3",
               "2, 3, 5"})
  public void should_compute_next_fibonnacci_number(int i, int j, int k) {
    assertThat(fibonnacci.computeNext(i, j), equalTo(k));
  }
}

sous forme de méthode si vos jeux de données sont amenés à être réutilisés:

public class MyFibonnacciTest {
  @Resource
  private Fibonnacci fibonnacci;
  @Test
  @Parameters(method = "getParametersForFibonnacciComputer")
  public void should_compute_next_fibonnacci_number(int i, int j, int k) {
    assertThat(fibonnacci.computeNext(i, j), equalTo(k));
  }
  private Object[] getParametersForFibonnacciComputer() {
    return $( $(1, 1, 2),
              $(1, 2, 3),
              $(2, 3, 5)
            );
  }
}

en créant un provider:

 public class FibonnacciProvider {
  public static Object[] provideFirstThreeFibonnacciNumbers() {
     return $( $(1, 1, 2),
               $(1, 2, 3),
               $(2, 3, 5)
             );
  }
  public static Object[] provideFirstFiveFibonnacciNumbers() {
     return $( $(1, 1, 2),
               $(1, 2, 3),
               $(2, 3, 5),
               $(3, 5, 8),
               $(5, 8, 13)
             );
  }
 }
public class MyFibonnacciTest {
  @Resource
  private Fibonnacci fibonnacci;
  @Test
  @Parameters(source = FibonnacciProvider.class)
  public void should_compute_next_fibonnacci_number(int i, int j, int k) {
    assertThat(fibonnacci.computeNext(i, j), equalTo(k));
  }
}

La version 0.2.0 est sortie le 16 mai dernier. Vous pouvez l’obtenir à l’adresse suivante : http://code.google.com/p/junitparams/.

Rétrospective de notre XKE de janvier

Xebia France — Fri, 07 Jan 2011 16:03:48 +0000

Nous étions tous réunis hier chez Xebia pour le premier XKE (Xebia Knowledge Exchange) de l’année 2011 !

Après nos échanges de vœux pour la nouvelle année et un bon café, la journée commença par deux sessions parallèles :

Une présentation de la gestion avancée de la mémoire en Java animée par Pablo Lopez. Ce slot se positionnait dans la continuité du concours de tuning de performance organisé l’année dernière.
Un débat autour du concept de DTO animé par Cyrille Le Clerc et Jean-Laurent De Morlhon.

Ce fut ensuite au tour de Michael Figuière de prendre la parole et d’esquisser les tendances des architectures de demain : Cloud, Elasticité, NoSQL, Scalabilité, etc.
Cette présentation a donné lieu à des débats animés.

Après un copieux déjeuner, nous avons accueilli Thomas Sarlandie, CTO de Backelite, qui nous a présenté leur solution de développement de services mobiles BkRender. Ce framework sera d’ailleurs testé lors de nos prochains XKE face à des alternatives comme JQuery Mobile, Flex pour Mobile, etc.

L’après midi s’est poursuivie par une présentation du plugin More Unit pour Eclipse par Nicolas Demengel, contributeur sur le projet.

Erwan Alliaume a ensuite animé un Hands On autour du framework Play!.

La journée s’est achevée par un retour d’expérience sur la mise en place de MongoDB / Amazon EC2 / S3 par Katia Aresti et Jean-Laurent De Morlhon (Cf. MongoDB en pratique).

Revue de Presse Xebia

Xebia France — Tue, 13 Jul 2010 05:45:49 +0000

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

Agilité

Le coin de la technique

Evènements de notre communauté en France et à l’étranger

Le programme du Devoxx 2010 se dévoile

Agilité

L’agilité à la sauce Pixar

C’est une question d’actualité avec la sortie de Toy Story 3 : mais comment Pixar fait-il pour cartonner à chaque nouveau film ? InfoQ lève une partie du voile : la cohérence construit la confiance. Derrière cette maxime ‘à l’américaine’ se cache un processus créatif original : Pixar construit des équipes pluri-disciplinaires, qui travaillent ensemble (éventuellement durant plusieurs films) et qui créent des liens de confiance inaliénables. Chaque jour, l’équipe se réunit pour discuter du travail effectué la veille : critiques, remises en cause, les équipes travaillent dans un processus d’amélioration constante. Chaque membre de l’équipe est encouragé à donner son avis, même ses membres les plus juniors.
Ce mode de fonctionnement laisse la place à l’erreur. Comme chacun est impliqué, chacun peut se tromper. Les erreurs sont mêmes une des clés du processus créatif. L’essentiel est de se tromper rapidement, pour pouvoir corriger le tir.

Changez maintenant de point de vue, et regardez cet article sous l’angle du développement logiciel. N’y retrouve t’on pas un fort goût d’agilité ?

Evitez le multi-tâches dans les équipes de développement

Toujours sur InfoQ, Roger Brown nous met en garde contre les méfaits du traitement simultané de projets (tâches, user stories …) par une personne.
Le changement de contexte lorsque l’on passe d’une tâche à l’autre peut prendre plus ou moins de temps en fonction de la complexité de la tâche, du temps et de la nature de l’interruption. Le traitement d’un appel téléphonique, par exemple, pourra engendrer un délai d’un quart d’heure pour se remettre dans le contexte de la tâche précédente. D’autres types d’interruptions (travail sur une autre tâche de développement par exemple) peuvent nous faire perdre beaucoup plus de temps.
L’auteur nous explique que le travail en parallèle sur plusieurs projets implique généralement un surcoût induit par les changements de contexte pouvant représenter de 20% à plus de 50% du temps de travail lorsque nous travaillons simultanément sur plus de deux projets. Il est donc préférable de terminer une tâche (User Story par exemple) avant d’en commencer une autre, plutôt que de fragmenter son travail.
Les méthodes agiles comme Scrum ou le Kanban préconisent un nombre limité de User Stories ou de tâches en cours, et de ne pas en commencer une autre avant d’avoir atteint le statut « Done ».
Le cerveau humain ayant tendance à vouloir traiter plusieurs tâches en parallèle, Roger Brown préconise quelques techniques telles que le pair-programming afin d’aider les développeurs à rester concentrés sur leur tâche et à gagner ainsi en efficacité.
On peut aussi citer le pomodoro qui est une discipline consistant à se ménager un laps de temps de 25 minutes sans interruption, permettant de se focaliser sur une tâche et ainsi de gagner en efficacité.
L’auteur conclut en ajoutant que non seulement le traitement séquentiel des projets (tâches, user stories …) permet de gagner du temps, mais il permet aussi de créer des synergies entre les différents membres de l’équipe qui peuvent ainsi travailler de concert sur le projet.

Le coin de la technique

Développez vos applications Android sans écrire une ligne de code

Google Labs vient d’annoncer l’arrivée d’App Inventor, un éditeur d’applications pour Android destiné aux non-développeurs. L’objectif est de permettre à tout androphile de dessiner sa propre application depuis le logiciel, puis de la transférer sur son smartphone.

To use App Inventor, you do not need to be a developer. App Inventor requires NO programming knowledge. This is because instead of writing code, you visually design the way the app looks and use blocks to specify the app’s behavior.

Pour le moment, il n’est pas possible de s’inscrire. Vous pouvez seulement montrer votre intérêt en remplissant un formulaire dans lequel vous exprimerez votre enthousiasme pour l’utilisation d’AppInventor dans un cadre universitaire. Si vous n’avez rien à voir avec quelconque formation, vous pouvez toujours laisser les réponses vides.

En épluchant le site, on constate la forte volonté d’installer cet éditeur dans le monde universitaire, voire scolaire. En effet, il est fait mention à plusieurs reprises des possibilités de développements de jeux, d’applications communautaires ou d’outils d’interaction entre étudiants. Malgré tout, Google n’oublie les autres… le particuliers lambda, ou le collègue que nous sommes en précisant:

The App Inventor team has created blocks for just about everything you can do with an Android phone, as well as blocks for doing « programming-like » stuff.

Nous nous posons tout de même quelques questions à ce sujet:

Google préfèrerait-il que nous apprenions à utiliser son logiciel plutôt qu’écrire du code propre personnalisé?
Ne se cache-t-il pas un envie de maîtriser le code généré? (en y ajoutant des statistiques par exemple…)
N’y a-t-il pas un risque de voir proliférer sur le market des applications réalisées en 5 minutes, pleines de pubs et pauvres sur les plans fonctionnel et graphique? (comme HelloPurr, cf. vidéo de démo)

Le futur nous le dira…

Du côté de la technique, les outils utilisés sont OpenBlocks et Kawa Language Framework. Le premier est le fruit de la thèse de Ricarose Roque (MIT) : une librairie Java permettant de programmer des systèmes à l’aide de blocs visuels. Le second est utilisé par le compilateur pour traduire en bytecode les blocs graphiques.

En attendant d’avantage d’informations et pourquoi pas un article plus complet sur l’outil, vous trouverez déjà quelques tutoriaux sur le site.

source : site de l’éditeur

Mettez à jour votre JVM

Après une dernière release qui corrigeait un problème de sécurité, Oracle nous invite à télécharger la release 21 qui, outre la correction de bugs (mais pas de correction liée à la sécurité), apporte des améliorations sur la JVM HotSpot et VisualVM.

Sur la Java HostSpot VM, les améliorations portent sur la compression des pointeurs d’objets, escape analysis (qui améliore la gestion des piles), la gestion du cache sur le byte code, sur le garbage collector CMS (Concurrent Mark-Sweep) et G1. Pour rappel, G1 est le nouveau garbage collector en préparation pour la JDK 7 mais déjà utilisable dans la version 6 depuis la release 17. Pour l’activer il faut passer les options -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC.

La version 1.2.2 de VisualVM, sortie il y a quelques mois, est à présent incluse dans la distribution de Java SE. Elle apporte beaucoup d’améliorations sur l’analyse de la mémoire et sur le profilage.

Enfin pour les développeurs de RIA java, un listener a été ajouté pour suivre l’évolution du chargement de l’application. Plus de détails ici.

Evènements de notre communauté en France et à l’étranger

Le programme du Devoxx 2010 se dévoile

J’espère que vous avez créé une règle sur votre outil de mailing préféré qui décline toute demande de réunion sur la période du 15 au 19 novembre 2010 car c’est … Devoxx!
À moins d’être parti 8 ans en mission dans l’océan arctique sur un brise glace, vous ne pouvez pas ne pas connaître Devoxx. C’est LA conférence européenne spécialisée sur LA technologie (i.e. Java) qui se déroule tous les ans à Anvers en Belgique.

Tout le gratin des meilleurs speakers et spécialistes sera présent dont certains français: Antonio Goncalves, Guillaume Laforge, Emmanuel Bernard pour ne citer qu’eux, mais aussi des incontournables comme Heinz Kabutz, John Smart ou bien Michael Cote.
Mais ce n’est pas tout! En effet, un BoF (Bird of Feather) organisé par les JDuchess se prépare.

Le programme commence à prendre forme. Vous pouvez commencer à saliver sur des conférences plus intéressantes les unes que les autres avec quelques titres accrocheurs:

JAX-RS, Java EE 6, and the future,
Reflection Madness,
Improve the performance of your Spring app,
HTML 5 Fact and Fiction,
Comparing JVM Web Frameworks,
Groovy update, ecosystem, and skyrocketing to the cloud with App Engine and Gaelyk,
Restfulie: quit pretending, use the web for real,
Women in IT an unconference,
etc.

Dans le programme de cette année, c’est surtout la présence de plus d’une dizaine de sessions dédiées aux technologies NoSQL et Cloud que l’on retiendra. On se souvient en effet que l’édition 2009 de cette conférence n’avait proposé qu’une trop courte session d’introduction à NoSQL suivie d’un BOF. Cette augmentation sensible de la part accordée à ces technologies témoigne de leur popularité croissante en 2010. Une fois de plus Devoxx s’affirme comme le baromètre de notre écosystème !

Revue de Presse Xebia

Xebia France — Mon, 01 Mar 2010 18:25:17 +0000

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

Actualité éditeurs / SSII

Agilité

Utilisez-vous des métriques intelligentes sur vos projets ?

Le coin de la technique

Actualité éditeurs / SSII

Sonatype ouvre son dépôt maven pour java.net

L’idée est venue d’une quantité toujours grandissante de plaintes sur les dépôts Maven fournis par java.net. A l’heure de la fusion annoncée entre Kenai et java.net, Kenai n’a aucune solution pour gérer les dépôts et java.net fait mauvaise presse sur ce point. Il n’aura pas fallu longtemps à Sonatype pour saisir l’opportunité de mettre en avant sa solution Nexus. L’éditeur propose donc à tous les projets java.net de migrer vers leur instance Nexus OSS, allant même jusqu’à organiser le 5 mars une grande journée migration, avec la mise à disposition pour tous des services de conseil et d’ingénierie interne. Outre la performance et la stabilité du dépôt Maven maintenu par Sonatype, Nexus génère des fichiers d’index utilisés par nos IDE pour rechercher les dépendances de nos POM.

La fusion JRockIt / Hotspot pas pour demain

Nous en parlions il y a quelques semaines, Oracle envisage de ne proposer à l’avenir qu’une seule JVM, qui tirerait le meilleur des deux que la firme s’est offert (JRockit via BEA, et Hotpsot via Sun). Dans un récent webcast (via InfoQ), Mark Reinhold s’est exprimé sur le sujet. Cette fusion n’est pas pour tout de suite : trop de clients utilisent les fonctionnalités spécifiques à l’une ou l’autre des JVMs en production, et il serait risqué de les forcer à migrer vers une version fusionnée bancale. Ce dernier se dit jaloux de certaines fonctionnalités de JRockIt et donc particulièrement excité d’avoir l’occasion de l’étudier en profondeur. Cependant, ce qui transparait dans son discours (et peut être via nos diverses expérience), c’est que la JVM de Sun est en avance sur celle de BEA. La prochaine version fusionnée devrait donc tendre plus vers Hotspot que vers JRockit. En résumé rapide, cette future VM Oracle devrait avoir les fonctionnalités runtime de Hotspot, et le garbage collector et la robustesse de JRockit. Finalement, à part l’ébauche d’une timeline, nous ne sommes pas beaucoup plus avancés.
Coté nouveautés du JDK 7, Mark Reinhold se dit aussi particulièrement excité par l’intégration du projet Coin (au contraire de la grande majorité des consultants Xebia, qui trouvent que la plupart de ces évolutions syntaxiques confinent au gadget).
Il reparle aussi des closures, principalement sous l’angle des raisons de la polémique, mais personne ne semble réellement savoir comment elles seront implémentées dans le JDK 7 (voir ci-dessous pour l’avancement du projet Lambda).
Dernière annonce, pour ceux qui comme lui sont impatients de voir une JVM enfin modulaire (aka Jigsaw, prévu dans le JDK 7, voir ci-dessous), ils devraient en avoir un aperçu mi-mars, avec la release 88 de l’OpenJDK.

Certains noteront avec un certain amusement (ou une certaine nostalgie) quelques ratés : « We, at Sun… »

Agilité

Utilisez-vous des métriques intelligentes sur vos projets ?

Mike Griffiths, agiliste expérimenté et bloggeur actif, nous présente sa réflexion sur l’utilisation des métriques dans un projet.
Au préalable, Mike nous prévient que :

Toutes les observations ne sont pas utiles et d’une grande aide pour analyser et comprendre un phénomène. Elles peuvent même amener à de mauvaises conclusions.
Certaines mesures très utiles ne sont pas facilement observables.

Une autre caractéristique à ne pas négliger est l’effet Hawthorne : L’observateur influence la mesure. On retrouve d’ailleurs ce phénomène en physique quantique. Mike nous explique alors que le fait d’observer et donc d’influencer la mesure, à un effet positif.

Pour lui, une métrique « intelligente » doit avoir les caractéristiques suivantes :

Simple et auto-générée.
Influence de manière significative ce que l’on cherche à observer.
Permet de prendre des décisions et décrire des tendances pour le futur.

Mike nous conseille de donner plus d’attention aux métriques permettant d’observer des tendances futures et d’anticiper.

On peut ainsi opposer aux vieilles métriques : nombres de lignes codées, points de fonctions réalisés ou nombres d’heures travaillées ; des métriques plus « intelligentes » : confiance des sponsors, satisfaction client, nombre de fonctionnalités réalisées, ou encore temps passé à la correction de bugs.

Dans la dernière partie de l’article sont présentés un certain nombre de métriques plus ou moins connues des agilistes, comme : le taskboard de Scrum ou Kanban. L’utilisation de métriques intelligentes est indispensable pour mener à bien un projet. Elles permettent d’observer des tendances, d’identifier et d’anticiper des problèmes; et ainsi, de prendre les bonnes décisions.

Le coin de la technique

Jigsaw, les modules du pauvre ?

Adam Bien est l’un des Java champions les plus visibles et les plus lus d’internet. Il a publié cette semaine un petit article au titre accrocheur : « Jigsaw / JDK 1.7 sera une solution qui permettra de répondre à 80% des besoins de modularité ». Vous avez probablement suivi les différents épisodes et rebondissements de la modularité dans le JDK 7. C’est peut-être l’occasion de faire le point sur ce que propose Jigsaw.

Le projet Jigsaw proposera une implémentation permettant la mise en place d’un système de modules bas niveau pour vos projets. Il sera également utilisé en interne pour découper le JDK Oracle/Sun lui-même.

Jigsaw vous permettra de choisir tout ou partie du JDK tout en restant 100% rétro-compatible, d’améliorer les temps de démarrage de la JVM et son utilisation mémoire.
Jigsaw pourra être utilisé directement sur vos projets si vous disposez d’une JVM reposant sur ce système. Jigsaw sera chargé avant rt.jar et sera donc disponible à quiconque désirant l’utiliser. Ce projet étant open source, il sera également possible de réutiliser celui-ci dans d’autres contextes.
Jigsaw vous permettra de rendre vos applications modulaires progressivement. Nul besoin de migrer vos applications dans leur ensemble pour tirer parti des bénéfices de la modularité. Un même package peut être éclaté dans plusieurs modules.
Contrairement à OSGi, Jigsaw ne vous permet pas le rechargement de modules à chaud. Vos modules sont chargés statiquement au démarrage de vos applications.
Tous vos modules sont chargés dans un même classloader, cela permet de simplifier grandement son utilisation. Du même coup, il vous sera probablement possible de ‘tricher’ en chargeant, au runtime, des classes d’un module sans que vous en ayez réellement le droit.

Si vous confondiez modularité du JDK avec OSGi, cette liste vous a certainement ouvert les yeux : Jigsaw vous propose une solution beaucoup moins fournie qu’OSGi.

Dans les faits, ce projet a été créé, avant tout, pour casser notre bon vieux JDK monolithique. Bon nombre de polémiques ont été faites sur ce choix. Pourquoi se contenter d’aborder 80% des problématiques de la modularisation avec une nouvelle solution alors qu’OSGi en aborderait 90% ? La simplicité et la souplesse d’utilisation ont été préférées à une solution décrite comme lourde (nécessitant beaucoup de glue), vieillissante (datant de 1998) et difficile à maîtriser. Ce choix a été sans conteste difficile à effectuer, il s’est ailleurs attiré les foudres des défenseurs d’OSGi, mais reste complètement défendable.

Comment les closures seront implémentées dans OpenJDK 7 ?

Fin 2009, le projet Lambda, dont le but est d’apporter les closures à la prochaine version de Java, apparaissait au sein d’OpenJDK. Le lancement du projet faisait suite aux rebondissements dans l’actualité du JDK 7 lors de la conférence Devoxx un mois auparavant. Une documentation montrant la syntaxe des closures avait accompagné la création du projet, plus tard, un draft d’une spécification plus formelle est apparue, mais quid de l’implémentation ?
Rémi Forax, contributeur au projet Lambda, a mis à disposition la présentation qu’il a faite au FOSDEM’10, dans laquelle il résume les discussions ayant eu lieu sur la mailing list du projet concernant les possibilités d’implémentation :

Convertir les closures en classes anonymes. Cette solution présente l’inconvénient de produire beaucoup de classes et pose problème pour certaines constructions liées au closures.
Convertir les closures en invocations dynamiques telles que le permettra la JSR-292 (Supporting Dynamically Typed Languages on the Java Platform). Cette solution ne produit pas de classes supplémentaires et bénéficie de bonnes performances puisque l’invocation dynamique présentera un temps d’exécution similaire aux invocations de méthode classiques.

Le reste de ses slides présente certaines des problématiques d’implémentations des closures liées à l’accès aux variables locales et aux champs de la classe hôte.

L’actualité des bases de données NoSQL toujours aussi riche

Depuis plusieurs mois maintenant le mouvement NoSQL s’est installé dans l’actualité. A Paris, le NoSQL User Group a attiré l’attention en réunissant une cinquantaine de personnes à chacune de ses 2 sessions jusqu’à présent.

D’un point de vue plus général, l’actualité des bases de données NoSQL est marquée par l’intérêt croissant qu’elles suscitent, et par leur évolution rapide grâce à l’effort soutenu de leurs développeurs. Ainsi on a pu noter récemment :

Neo4j, une base de données orienté graphe, est maintenant disponible en version 1.0 finale. L’intérêt de la représentation en graphe est la possibilité de modéliser les données relatives aux réseaux sociaux, mais également tout type d’objets qui seraient liés entre eux de manière arbitraire. De plus, il est possible d’appliquer à ces données divers algorithmes de graphe classiques tels que la détermination du plus court chemin entre deux objets ou de l’objet central/majeur dans un nuage d’élément.
Cassandra vient pour sa part d’être publié en version 0.5.1, et connait un succès tout particulier puisque Twitter vient d’annoncer qu’il l’utiliserait désormais comme solution de persistance en remplacement de MySQL. Par ailleurs le projet Lucandra a été créé récemment pour permettre d’utiliser Cassandra comme solution de persistance pour les indexes Lucene. Donné à la Fondation Apache par Facebook, Cassandra est pour rappel un hybride entre BigTable de Google et Dynamo d’Amazon.
HBase profite d’une communauté très active et d’un intérêt important, renforcé par sa position de sous-projet du très populaire Hadoop. Sematext vient de publier un digest de l’actualité récente de ce projet. Celle-ci est principalement marquée par le développement d’une réplication multi datacenter, par l’arrivée d’un plugin DataNucleus pour HBase et par la disponibilité prochaine d’une solution de benchmark pour les cloud storages développée par Yahoo!.

Enfin, deux conférences entièrement dédiées au NoSQL sont à venir : NoSQL Live le 11 mars à Boston et, plus proche de nous, NoSQL Europe du 20 au 22 avril à Londres.

Astuce de la semaine, récupérez la liste complète des options de votre JVM

Cette astuce est complètement inutile, et donc également complètement indispensable. Cet article nous propose une petite commande permettant de récupérer la liste complète des options de votre JVM Hotspot à partir de sa library native Linux, la voici :

prompt$  strings $JAVA_HOME/jre/lib/amd64/server/libjvm.so | grep -B646 assert_null$ | grep -v '{' | grep -v '&' | grep -v '/' | grep -v '%' | grep -v assert_null

Revue de presse

Xebia France — Mon, 21 Sep 2009 17:35:00 +0000

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

Actualité éditeurs / SSII

Agilité

Pair programming à distance sous Eclipse avec Saros

SOA

L’initiative REST-* fait débat

Le coin de la technique

Evènements de notre communauté en France et à l’étranger

Soirée Tontons Flexeurs le 24 Septembre

Actualité éditeurs / SSII

Google lance son langage pour la JVM

Lors du JVM Language Summit de la semaine dernière, Google a présenté son nouveau langage pour la JVM appelé Noop. Le Wiki du projet et sa présentation permettent de faire le tour des spécificités de ce langage :

Syntaxe prévue pour être facilement compréhensible par un développeur Java ou C++
Pas de types primitifs, pas de classes ou méthodes statiques, variables non mutables par défaut, pas de syntaxe optionnelle, exceptions uniquement de type unchecked
Librairie standard s’appuyant sur JodaTime, util.concurrent et Google Collections
Support natif du concept d’injection de dépendances offert par Guice ou PicoContainer, un type est alors soit newable soit injectable
Support natif des tests unitaires qui ont leur structure dédiée sans classes ni méthodes

Les réactions qui ont suivies cette annonce montrent en général un intérêt couplé à une réserve légitime due à l’état embryonnaire du projet. Ainsi l’analyse de Dominique de Vito s’inscrit dans ce schéma, tandis qu’Alexis Moussine-Pouchkine, Sun, explique à 01net qu’il trouve enrichissant la profusion de nouvelles idées mais que, selon lui, le langage Java restera malgré tout omniprésent pendant encore des années.

Reste que là où de nombreux nouveaux langages justifient leur existence par une syntaxe plus compacte, une nature dynamique ou encore des concepts élaborés, Noop semble adopter une approche plus pragmatique et plus proche des besoins quotidiens rencontrés en informatique de gestion. L’avenir nous dira si les apports de ce langage sont suffisants pour convaincre des équipes de le préférer à Java pour leurs développements.

iBeans : la solution d’intégration pour applications Web de MuleSoft

MuleSource, récemment renommé en MuleSoft lors du lancement de leur offre Tcat Server a récemment diffusé une première beta public d’un nouveau produit : Mule iBeans. Il s’agit d’une nouvelle solution d’intégration s’attaquant à un marché différent des ESB traditionnels. MuleSoft part en effet du constat que de nombreuses applications Web doivent s’intégrer avec diverses ressources distantes, mais ne peuvent s’appuyer sur un ESB qui constituerait une solution trop lourde. iBeans se positionne ainsi en tant que solution d’intégration pour applications Web. La nuance est légère par rapport aux ESB mais on constate clairement cette orientation dans la pratique : annotations, composants iBeans, injection de services type IoC avec un contexte request, …

La particularité principale du projet est son modèle de composant iBeans. Il s’agit de composants similaires aux Beans Spring ou aux Session Beans EJB mais spécialisés dans l’accès à un service à distance. Ces composants utilisent certaines annotations de la récente JSR-330 (Dependency injection for Java) et peuvent s’intégrer facilement avec Spring, Struts et JSF.

MuleSoft propose parallèlement un projet nommé Community iBeans Proposals visant à regrouper les iBeans de la communauté pour intégrer les ressources les plus fréquentes.

iBeans répond à un besoin courant des applications Web. La réponse proposée par MuleSoft est élégante mais on pourra regretter l’apparition d’un modèle de composant supplémentaire disposant de son propre cycle de vie. Actuellement l’éditeur n’a pas communiqué sur son projet naissant en dehors de la page Wiki dédiée. Une recherche Google montre rapidement que la communication autour de ce projet est quasi inexistante. Toutefois, une session dédiée au sujet prévue pour Devoxx 2009 tend à nous faire penser que la célèbre conférence européenne pourrait bien servir de rampe de lancement au nouveau projet de MuleSoft.

Agilité

Pair programming à distance sous Eclipse avec Saros

L’université de Berlin propose depuis quelques temps un plugin Eclipse nommé Saros, offrant des fonctionnalités permettant le pair programming à distance grâce au protocole XMPP. Concrètement les possibilités sont :

Reproduction ou synchronisation d’un projet Eclipse à distance via une connexion XMPP.
Visualisation dans l’environnement de l’observer des classes ouvertes et de la classe en cours d’édition par le driver.
Affichage en temps réel des modifications du code, et de la position du curseur et du texte sélectionné.
Gestion expérimentale d’un mode multi-driver permettant de modifier le code à deux simultanément.
Chat via une vue dédiée dans Eclipse

Un screencast est proposé sur le site du projet, celui-ci permet de se rendre compte des capacités du plugin.

Idéalement complété d’une conversation Skype, ce plugin trouvera sa place dans de nombreux scenarii allant du distributed pair programming à l’assistance d’un collègue situé à un autre étage.

SOA

L’initiative REST-* fait débat

JBoss vient de lancer le site REST-*.org hébergeant son initiative de standardisation de plusieurs services middleware traditionnels sur le modèle REST.

Actuellement deux drafts sont en cours de rédaction, l’un porte sur RESTful Messaging, l’autre sur RESTful Transactions. Ces deux spécifications visent à définir un ensemble d’URIs standards sur le modèle REST permettant d’exposer une ressource transactionnelle ou un broker de messages.

Très rapidement, de vives réactions sont apparues au sein de la communauté, principalement pour faire part de leur scepticisme quant à cette initiative, régulièrement comparée à la très lourde collections de spécifications WS-*, qui pourrait mettre à mal la simplicité unanimement reconnue du modèle REST. C’est ainsi le cas d’Anne Thomas Manes qui revient également sur les critiques de Bill Burke à l’égart de l’initiative RestMS qui existait déjà et qui pariait plutôt sur Atom et AMQP.

Bill Burke de son coté publie sur son blog un billet par jour depuis la publication sur le site REST-*.org, pour justifier ses choix et la légitimité du projet qu’il porte. Ses arguments portent principalement sur le fait qu’il existe une demande très forte de la communauté pour gérer les services de messaging et les transactions avec REST.

Le débat est compréhensible : la volonté d’exposer certaines ressources transactionnelles ou services de messaging s’inscrit dans les besoins courants des entreprises, tout comme les craintes de voir se reproduire les erreurs du passé sont légitimes. L’apport de cette initiative est donc probablement de porter sur le devant de la scène une réflexion sur un problème pourtant courant et déjà exposé par Leonard Richardson et Sam Ruby, il y a deux ans, dans leur livre majeur RESTful Web Services.

Le coin de la technique

OSGi 4.2

OSGi est sur le devant de la scène, d’InfoQ à OSGi Thoughts en passant par The Programming Delusion (BJ Hargrave, CTO de l’OSGi Alliance), depuis une petite semaine et pour cause : l’OSGi Alliance a sorti et mis à disposition le 16 septembre dernier les spécifications finales de la version 4.2 (téléchargeables ici).

Alex Blewitt nous résume la situation sur InfoQ. On retiendra qu’Equinox et Félix ont déjà commencé leur travail de compatibilité avec OSGi 4.2. Les spécifications étant désormais released, ce n’est qu’une question de temps avant que les projets affichent fièrement leur label OSGi 4.2 compliant.
On notera aussi une nouvelle méthode de lancement du runtime OSGi, le nouveau nom des Distributed OSGi qui deviennent les Remote Services (connexion de VMs OSGi), les Blueprint Services qui seront des services wired à la Spring, le concept de Bundle Tracker ou bien encore le mécanisme de permission sur une opération dans un bundle.

Pour la petite piqure de rappel, on pourra se tourner vers JavaLobby qui nous propose depuis quelques jours 2 tutoriaux HelloWorld sur OSGi, le premier avec Swing et le second avec Spring RC.
Et pour les plus nostalgiques, le Paris JUG sur OSGi, c’était (déjà) il y a 1 an…

Scala OSGi-fié

On reste dans les news OSGi avec un projet qui propose Scala 2.7.6 en version OSGi-fiée (vu ici).

Comme expliqué sur le GitHub du projet, Scala n’est pas (encore) packagé en bundle OSGi. Certes, le plugin Eclipse Scala IDE utilise un bundle OSGi qui embarque Scala mais celui-ci ne peut pas être utilisé de manière générale (manifest spécifique et toutes les librairies dans un seul jar).

scala-lang-osgi répond à ce besoin et fournit un bundle OSGi pour chaque librairie Scala. Le tout est disponible sur le repository maven scala-tools.org.

Astuces de performance pour MySQL

Même si nos ORMs préférés génèrent des requêtes optimisées à notre place, il arrive parfois que, pour des raisons de performances ou autres, l’on doive écrire certaines requêtes directement en SQL.
Le site Debian Admin (par Code Purity) référence à cette fin 84 astuces d’optimisations de performances pour MySQL.
Certes, la plupart des astuces de configuration de MySQL sont peut-être/certainement déjà mises en place par nos chers DBA. Mais on trouvera aussi une pléiade d’astuces concernant la requête elle-même : cela passe de la non utilisation du gourmand SELECT *, d’éviter au possible l’utilisation de DISTINCT (très consommateur), d’utiliser pour l’insertion des BATCH INSERT et REPLACE ou bien encore l’utilisation INET_ATON et INET_NTOA au lieu de CHAR et VARCHAR pour les adresses IP.
Pour le détail complet, rendez-vous directement sur le site de Debian Admin.

Enquête sur les temps de redémarrage des serveurs JEE

ZeroTurnAround, l’éditeur de JRebel, a mené (et continue même à collecter des données) une étude sur les temps de redémarrage / redéploiement des serveurs d’applications auprès des lecteurs de son blog (environ 700 personnes ont répondu).
Tout d’abord, passons sur la conclusion évidente de l’étude, vous avez besoin de JRebel, pour tenter de voir au delà de cette évidence marketing. On évitera aussi la polémique sur le rapprochement Conteneurs de Servlets / Serveurs d’applications.
On constate tout d’abord que la population fréquentant le blog de ZeroTurnAround (on a donc dès le début une information en partie biaisée) a une forte tendance à confier ses applications à une plate-forme basée sur Tomcat (JBoss + Tomcat), plutôt qu’aux historiques IBM et ~~BEA~~ Oracle. Là encore, étant donné la notoriété naissante de JRebel, au sein d’une communauté plutôt tournée vers l’open source, rien d’étonnant.

En revanche, il est intéressant de constater que les temps de redéploiement deviennent assez rapidement délirants, avec des serveurs qui en moyenne mettent entre 2 et 5 minutes à redémarrer, la palme de la lenteur revenant, on le savait déjà par expérience, aux gros serveurs monolithiques commerciaux. Alors, au-delà du constat qu’un développeur passe aujourd’hui une grande partie de son temps à attendre que son application se mette à jour sur son serveur d’applications, au-delà du fait que JRebel est une des manières d’adresser ce problème, nous nous posons la question suivante : est-il normal, pour un serveur d’applications, de mettre cinq minutes à redémarrer ?

L’actualité de cette revue de presse met en avant OSGI, qui sera certainement une des réponses apportées à cette explosion des temps de démarrage. Ce sont d’ailleurs les absents de cette étude qui porteront la première estocade : GlassFish 3.x et dmServer.

Premiers pas avec memcached

Dans le but de proposer une implémentation d’un système de cache pour Grails, James Goodwill, sur DeveloperWorks, propose, dans un premier temps, une découverte du système de cache distribué memcached.
Une mise en bouche qui permet de découvrir les bases de ce produit, avant de combiner ce cache avec Grails dans une seconde partie, qui, on l’espère, permettra d’optimiser les performances du plus célèbre des frameworks haute productivité.

Evènements de notre communauté en France et à l’étranger

Soirée Tontons Flexeurs le 24 Septembre

Suite des Tontons Flexeurs, après la très bonne soirée Flex et Java en entreprise, avec une nouvelle session ce jeudi 24 septembre. 2 invités de marque : Mike Chambers et Lee Brimelow qui nous feront une présentation d’Adobe AIR (techniques avancées de synchronisation de données, de manipulation de fichiers, possibilités d’intégration à la plateforme hôte…) et des nouvelles fonctionnalités des prochaines versions de AIR.

A l’heure où nous écrivons ces lignes, il reste encore quelques places disponibles donc rendez-vous sur le formulaire d’inscription de l’évènement.

Ce que vous avez peut-être raté au quatrième trimestre 2008

Xebia France — Fri, 02 Jan 2009 10:56:49 +0000

Voici la liste des billets les plus lus sur ce blog en octobre, novembre et décembre :

RIA Contest : Flex / Silverlight / GWT / Echo3 / JavaFX

Après le Xebia Web Framework Contest de l’année dernière, le thème du XKE du mois d’Octobre était un nouveau contest dédié aux RIA.

Le but de cette journée était de développer une application de gestion de playlist de morceaux de musique. En promoteurs des méthodes Agiles, les spécifications furent données sous forme d’un Product Backlog. Trois sprints d’une durée de 90 minutes ont permis à tous de suivre l’évolution des différentes réalisations. Un web service SOAP fournissait les différentes données: Artiste, Album, Titres et Pochettes d’album.

Cinq équipes ont été constituées, cinq frameworks ont donc été choisis :

Au terme de cette journée, chaque équipe a pu exprimer un retour d’expérience significatif.

Lire cet article »

Diagnostic d’une JVM à distance

Développer une application Java, c’est bien. La rendre performante, c’est mieux.

Cependant, qui dit « performance », dit « mesure ». En effet, il est nécessaire de pouvoir :

connaître les paramètres de lancement de la JVM,
mesurer l’empreinte mémoire et le comportement du Garbage Collector,

Cet article va décrire dans une première partie les différents outils permettant de collecter ces informations en local. La seconde partie se concentre sur les moyens pour obtenir ces mêmes informations à distance.

Lire cet article »

Analyse mémoire d’une JVM

Mardi, 10 heures
- La production « Allo, le projet, depuis 10 minutes on voit passer des messages ‘OutOfMemoryError’. Que fait-on ? «
- Le projet « Augmentez la mémoire de la JVM, doublez-la valeur de l’option -Xmx «

Mardi, 13 heures
- La production « Allo, le projet, depuis 5 minutes on voit encore passer des messages ‘OutOfMemoryError’. Que fait-on ? «
- Le projet « Augmentez la mémoire de la JVM, doublez encore la valeur de l’option -Xmx «

Mardi 18 heures
- La production « Allo, le projet, depuis 2 minutes on voit passer encore des messages ‘OutOfMemoryError’. Que fait-on ? «
- Le projet « Tut, tut, tut,….. »
- La production « Plus d’équipe projet, la nuit va être longue… »

Cette petite scène est un classique, un air de déjà-vu mais que faire ? Si votre application a déjà subi une batterie de tests techniques, augmenter la mémoire est rarement la bonne solution. La scène décrite ci-dessus laisse penser à ce que l’on appelle classiquement une Fuite Mémoire (Memory Leak). En réalité, avec les JVM récentes, la fuite mémoire n’existe pas, je préfère parler d’accumulation d’objets non désirés. Cet article va vous montrer comment débusquer cette accumulation avec les outils jmap, jhat et Eclipse Memory Analyser.

Lire cet article »

Analyse mémoire d’une JVM

Benoit Moussaud — Thu, 27 Nov 2008 13:04:40 +0000

jmap

jmap est l’outil qui permet d’effectuer des photographies de la mémoire d’une JVM. Deux options sont particulièrement intéressantes : l’histogramme et le dump.

L’histogramme

L’option -histo permet d’obtenir un histogramme de la mémoire de la JVM. Les informations suivantes sont affichées pour chacune des classes Java :

son nom complet
le nombre d’objets et
la taille de la mémoire occupée en octets

L’ensemble est trié par taille mémoire décroissante. Attention, la demande d’un histogramme implique automatiquement un Full GC de la mémoire de la JVM.

Exemple :

jmap -histo 
 num     #instances         #bytes  class name
----------------------------------------------
   1:         41202       27502288  [C
   2:          2304        1332520  [I
   3:         37934         910416  java.lang.String
   4:          5130         503632  
   5:          5130         412968  
   6:         12348         395136  fr.xebia.memory.bean.Person
   7:         12846         308304  java.util.concurrent.ConcurrentHashMap$HashEntry
   8:          7650         285656  
   9:         12518         200288  java.lang.Long
  10:           349         189184  
  11:           349         138704  
  12:           327         132144  
  13:            38         115456  [Ljava.util.concurrent.ConcurrentHashMap$HashEntry;
  14:           414          76392  [B
  15:           422          40512  java.lang.Class
  16:           556          32656  [[I
  17:           518          32056  [S
  18:            44          14080  
  19:           315          13480  [Ljava.lang.Object;
  20:           576           9216  java.lang.StringBuffer
.....
 184:             1              8  java.lang.System$2
 185:             1              8  java.io.File$1
 186:             1              8  java.lang.Terminator$1
Total        142211       32693376

Que peut-on en déduire ?

Les premières places sont souvent trustées par les objets de base ( java.lang.String, java.lang.Object, java.lang.class) et leur déclinaison en collections (java.util.* et les tableaux, symbolisé par des '['). Si vous retrouvez des classes de votre application dans le top 20, elles deviennent suspectes. Dans notre exemple, l'histogramme montre que la classe 'fr.xebia.memory.bean.Person' est instanciée 12348 fois pour une occupation mémoire de 308304 octets. Elle est suivie de près par des entrées d'une ConcurrentHashMap (java.util.concurrent.ConcurrentHashMap$HashEntry)
L'obtention de cet histogramme est extrêmement rapide ~~et perturbe peu la JVM (au Full GC près ;~~) ). Il est donc possible d'en faire régulièrement (exemple toutes les 'n' secondes) et d'en déduire ainsi des tendances : nombre d'instances d'une classe qui augmente, taille des instances d'une classe qui diminue, ...

Note : avec les JVM en version 1.4.2, il est possible d'obtenir également un histogramme à chaque thread dump en ajoutant l'option -XX:+PrintClassHistogram au démarrage de la JVM. Comme pour jstat -histo, cette option implique automatiquement un Full GC de la mémoire de la JVM.

L'histogramme permet de connaître les classes qui occupent le plus de mémoire, il n'indique pas qui les a allouées.

Le dump

L'histogramme c'est bien, mais ce n'est pas suffisant : il est parfois nécessaire d'obtenir un dump complet de la mémoire afin de déterminer précisément la chaîne de référencement.

L'outil jmap permet également d'effectuer un dump complet et binaire de la mémoire d'une JVM. Deux remarques importantes :

pendant la durée du dump, plus rien ne s'exécute dans la JVM, tous les threads sont stoppés, qu'ils soient applicatifs ou systèmes.
la durée du dump est proportionnelle à la taille de la mémoire occupée et fonction de la taille de la mémoire restante (il faut un peu de mémoire libre pour exécuter le traitement du dump !). Exemple: la durée d'un dump d'une JVM avec un heap de 1 Go à la limite de la saturation mémoire se compte en minute !

Exemple : création d'un dump

jmap -dump:format=b,file=c:tempheap.bin 
Dumping heap to c:tempheap.bin ...
Heap dump file created

Note : L'option -XX:+HeapDumpOnOutOfMemoryError indique à la JVM d'effectuer un heap dump en cas d'OutOfMemoryError. Le fichier est généré dans le répertoire de lancement de la JVM.

Vous voilà l'heureux propriétaire d'un fichier binaire de plusieurs centaines de méga-octets. Comment en extraire des informations ? C'est là que le compagnon de jmap rentre en jeu : jhat.

jhat

jhat est un analyseur de dump mémoire. C'est en réalité un serveur web, comme le montre l'exemple ci-dessous.

D:ProjetsMesProjetsMemoryLeakjmap5968>jhat heap5968.bin
Reading from heap5968.bin...
Dump file created Mon Nov 24 13:03:54 CET 2008
Snapshot read, resolving...
Resolving 118955 objects...
Chasing references, expect 23 dots.......................
Eliminating duplicate references.......................
Snapshot resolved.
Started HTTP server on port 7000
Server is ready.

L'application jhat lancée, il suffit de lancer un navigateur web pour commencer l'exploration du dump.

[ MODE PLEIN ECRAN ]

Grâce à jhat, on a pu voir que les instances de type fr.xebia.memory.bean.Person étaient majoritairement référencées par un champ statique de type fr.xebia.memory.dao.MySuperSmartCache qui fait office de cache. Sans rentrer dans le code, on peut commencer à avoir des doutes sur l'efficacité de ce cache !

jhat a l'avantage d'être disponible dans tous les JDK récents. Cependant, l'interface proposée permet certes de naviguer facilement de classe en classe, d'instance en instance, mais il manque de fonctions d'analyse. Un outil est venu combler ce manque...

Eclipse Memory Analyzer

Eclipse Memory Analyzer (MAT) est un sous projet de la fondation Eclipse, initié par la société SAP. Son but est non seulement d'offrir une interface graphique permettant de naviguer dans un dump mémoire, mais également de proposer des rapports d'analyses précablés (Leak Suspects, Heap Dump Overview, Top Consumers,...).

Ouvrons le dump avec MAT. Après analyse, MAT ouvre une fenêtre avec une vue d'ensemble de la mémoire. Il est clair que l'ensemble de la mémoire est retenu par une seule instance de type fr.xebia.memory.dao.Loader.

La vue histogramme ressemble à celle fournie par jmap ou jhat mais avec des libellés un peu plus clairs.

Une fonction très intéressante, le 'Dominator Tree' donne la liste des plus gros objets, consolidée avec l'ensemble de leurs références.

Pour terminer, jetons un coup d'œil sur le rapport 'Leak Suspect', et là il n'y a plus de doute, nous avons trouvé le coupable.

Conclusion

Avec ces outils de capture et d'analyse de la mémoire, il est maintenant facile de débusquer les consommations mémoires excessives, même dans un environnement de production. N'hésitez pas à user et à abuser de ces outils afin de déterminer au plus tôt les tailles des JVM et les éventuelles accumulations d'objets non désirés !

Revue de Presse Xebia

Xebia France — Mon, 27 Oct 2008 17:49:53 +0000

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

Actualité éditeurs / SSII

Le coin de la technique

Actualité éditeurs / SSII

Google Android disponible en Open Source

Google a officiellement mis à disposition le code source de la plateforme Android et encourage les développeurs à la tester.

Cette annonce survient au moment du lancement du nouveau téléphone le HTC Dream G1 de HTC par T-Mobile aux États-Unis. Le code source est livré sous licence Apache, ce qui implique que son utilisation est gratuite et que les développeurs ne sont pas tenus de rendre public le code source de leurs nouveaux produits.

Le code source d’Android est à présent disponible au téléchargement à l’adresse suivante : http://source.android.com/download.

Quant à ceux qui souhaiteraient développer des applications pour ces téléphones, Google recommande Ubuntu comme environnement de programmation pour Android (il est également possible d’utiliser MacOS).

Amazon EC2 passe en production

Le service d’hébergement d’applications Amazon EC2 n’est plus une bêta depuis le 23 octobre. Aurait-on donc de nombreux changements à se mettre sous la dent ?
Pas vraiment. La seule « révolution » est l’introduction d’un SLA (Service Level Agreement, autrement dit un engagement de résultat) qui garantit une disponibilité à 99.95% du temps. Si le taux de service chute sous cette barre, le client peut remplir une demande et accéder à des remises commerciales (autant dire qu’Amazon a dû considérablement stresser son système avant d’annoncer de tels chiffres).

Dans un futur proche, le service d’Amazon devrait se voir enrichi des fonctionnalités suivantes :

Console d’administration.
Load Balancing.
Adaptation automatique à la charge (AutoScaling).
Monitoring global de l’ensemble des instances.

ainsi que de nouveaux logiciels : Windows Server 2003, SQL Server Standard 2005 ou Express (déjà disponibles en bêta), Windows Server 2008 (à venir)

Une nouvelle pierre dans le jardin des hébergeurs traditionnels…

Le coin de la technique

Sortie de Seam 2.1.0.GA

Dans une précédente revue de presse, nous vous avions présenté les nouveautés de Seam 2.1. L’équipe Seam concrétise ces nouveautés avec la sortie officielle de Seam 2.1.0.GA.

Seam 2.1.0.GA intègre les composants suivants :

RichFaces 3.2 (implémentation JSF de JBoss).
GWT (Google).
Wicket (Apache) (exemple d’intégration de Wicket dans Seam : Seamless Wicket: Orchestrating your application).
Groovy 1.5 (pour rappel il est possible d’écrire des composants Seam avec le langage Groovy).
JBoss Cache 2 (ou JBoss Cache ou EHCache).
JAX-RS (REST) via l’implémentation du projet JBoss RestEasy.
A noter que RestEasy n’est actuellement qu’en version bêta.
Documentation pour intégrer Seam dans d’autres containers que JBoss AS : WebLogic, WebSphere, OC4J et Glassfish.

Prochaine étape : Seam 2.1.1, l’équipe s’attachera à encore améliorer les performances, la scalabilité et le clustering de Seam.

En parallèle, la spécification Web Beans commence à pointer le bout de son nez : Web Beans Teaser.

Félicitation à l’équipe Seam pour le travail qui a été réalisé.

JBoss AOP 2.0.0 disponible, JBoss AS 5 se rapproche …

La sortie officielle de la version 2.0.0 de JBoss AOP vient d’être annoncée. Après s’être posé la question en début de semaine, Kabir Khan a finalement décidé de publier celle-ci. Doit-on y voir les signes avant-coureurs d’une sortie imminente du nouveau serveur d’applications made in JBoss ? Il est encore un peu tôt pour le dire. Notez tout de même que JBoss AS 5 est en RC2 depuis déjà plus d’un mois, date à laquelle il avait franchi la plus grande marche lui restant à gravir (La Certification JEE).

Pour en revenir au cœur du sujet, si JBoss AOP est directement intégré au sein du futur serveur d’applications, rien ne vous empêche d’utiliser celui-ci en standalone. La meilleure présentation de ce framework reste l’article de 5 pages publié sur DZone cet été : An Introduction to Aspect-Oriented programming with JBoss AOP qui en présente les principales nouveautés :

Un nouveau mode de weaving permettant l’ajout d’advices autour des exceptions (before / after / throwing / finally).
L’interception des accès à chaque élément d’un tableau.
Un déploiement et une mise à jour à chaud des advices et des interceptors.
Une intégration avec le microcontainer JBoss AS 5.

Autres liens :

Embedded Jopr pour JBoss AS : une console JMX de nouvelle génération

JBoss vient de mettre à disposition de la communauté une console JMX nouvelle génération pour la supervision et l’administration d’une instance du serveur JBoss AS. La console est une application web basée sur le framework Seam. Le code source de l’application est livré sous licence LGPL.

Une particularité de la nouvelle console est la possibilité d’intégrer des plugins de RHQ et Jopr.

La version 1.0 offre la possibilité de gérer l’instance du serveur et les instances des applications d’entreprise, de mettre à jour les configurations, de contrôler les activités et d’exécuter les scripts qui résident dans le répertoire bin du serveur JBoss AS.

Une capture d’écran de la console :

Une présentation vidéo flash de la console Embedded Jopr en action : http://www.jboss.org/embjopr/demo.html#.

Exemples de la JSR 203 (la nouvelle nouvelle JSR I/O)

Les exemples concernant cette JSR NIO2 (dont nous vous parlions déjà dans une revue de presse précédente) continuent d’affluer.

Récemment, c’est Alex Miller (examples and more features) qui nous propose des exemples d’utilisation balayant quelques nouvelles fonctionnalités de cette API.

Parmi ces changements, et pour ne garder que ceux qui nous simplifieront la vie (et surtout les lignes de code), nous retiendrons :

L’objet central n’est plus File mais Path : il faudra donc, comme pour le Path d’Eclipse RCP, raisonner en « segments » (une liste de noms) représentant une hiérarchie, le dernier niveau représentant le fichier ou le dossier pointé.
Méthodes copyTo et moveTo directement intégrées à l’objet : et oui, terminé les Streams pour une copie ou un déplacement ! Il suffit d’avoir le Path d’origine, de définir le Path de destination et d’opérer directement l’opération souhaitée telle que fromPath.copyTo(toPath) ou fromPath.moveTo(toPath).
Itérateurs améliorés : recherche de fichiers à partir d’un filtre (DirectoryStream) ou d’un visiteur (SimpleFileVisitor). Là encore, on a la possibilité d’effectuer un traitement métier soit sur un type de fichier spécifique (défini par exemple par l’extension du fichier) soit sur tous les fichiers présents dans un dossier.

// Filter
DirectoryStream xmlFiles = myFolderWithXmlFiles.newDirectoryStream("*.xml");
for (Path xmlFile : xmlFiles ) {
   // Stuff...
}
// Visitor
Files.walkFileTree(myFolerToVisit, new SimpleFileVisitor() {
   public FileVisitResult visitFile(Path file, BasicFileAttributes attrs) {
      // Stuff...
   }
});

Lecture des attributs des fichiers dont les principaux sont :

// Standard file attributes
BasicFileAttributes attrs = Attributes.readBasicFileAttributes(Path.get("test.xml"), true);
TimeUnit scale = attrs.resolution();
new Date(scale.toMillis(attrs.creationTime));
new Date(scale.toMillis(attrs.lastAccessTime));
new Date(scale.toMillis(attrs.lastModifiedTime));
attrs.isDirectory();attrs.isFile();attrs.isSymbolicLink();attrs.isOther();attrs.size();
...
// Dos file attributes
DosFileAttributes attrs = Attributes.readDosFileAttributes(Path.get("test.xml"), true);
attrs.isArchive();attrs.isReadOnly();attrs.isHidden();attrs.isSystem();
...
// Posix file attributes
PosixFileAttributes attrs = Attributes.readPosixFileAttributes(Path.get("test.xml"), true);
attrs.permissions();attrs.owner();attrs.group();
...

Cette très attendue API est prévue pour Java 7.

JVM 64 bits ? Oui mais avec compression des pointeurs

La généralisation des processeurs x86 et des systèmes d’exploitation 64 bits amène les exploitants à étudier l’utilisation de JVM 64 bits pour les serveurs d’applications Java. Si les JVM 64 bits permettent d’allouer de larges heap (> 3 Go), l’augmentation de la taille des pointeurs (de 4 à 8 octets) nuit aux performances et à la consommation mémoire (cf Revue de Presse du 26/05/2008).

C’est ce que montre David Dagastine, Java Platform Performance Lead, dans son article SpecJbb2005, la mémoire allouée à la JVM 64 bits est le double de celle allouée à la version 32 bits alors que les performances de cette version 32 bits sont tout de même 13% meilleures que celles de la version 64 bits.

Marcus Lagergren (BEA Systems) et Bob Kasten (Intel) exposent la parade mise en place par BEA :
Oracle/BEA : Aim High with JRockit on Intel Architecture

JRockit 64 bits offre depuis la version 5.0-R26.4 un mécanisme de compression des pointeurs (-XXcompressedRefs, activé par défaut si la taille de la heap est inférieure à 4 Gb) pour concilier les performances et la consommation mémoire des JVM 32 bits avec l’allocation de larges Heap spécifique aux 64 bits.

JRockit 5.0 R26-4 release notes : « Compressed references has greatly increased the performance on 64-bit platforms. »

Aujourd’hui, seuls les mécanismes de compression de pointeurs disponibles sur les JVM JRockit 5.0+ et IBM 6.0 permettent d’utiliser des JVM 64 bits sans dégradation des performances (10-20%) ni augmentation de la consommation heap (> 50%). Ces mécanismes ne sont pas encore disponibles sur la JVM de Sun.

Pour conclure, on citera les communications « officielles » de Sun et d’IBM sur ce sujet :

Sun : FAQ About the Java HotSpot VM / What are the performance characteristics of 64-bit versus 32-bit VMs?

« Generally, the benefits of being able to address larger amounts of memory come with a small performance loss in 64-bit VMs versus running the same application on a 32-bit VM. This is due to the fact that every native pointer in the system takes up 8 bytes instead of 4.
…
The performance difference comparing an application running on a 64-bit platform versus a 32-bit platform on SPARC is on the order of 10-20% degradation when you move to a 64-bit VM. »

IBM Java Technology Center: What’s the Difference Between 32 and 64 Bit Java? (pdf)

« At Java 5, 64 bit can be around 20% slower than corresponding 32 bit runtime
…
We assume a ~20-30% increase in object size heap consumption – but can be much larger »

Diagnostic d’une JVM à distance

Benoit Moussaud — Wed, 22 Oct 2008 08:28:07 +0000

Développer une application Java, c’est bien. La rendre performante, c’est mieux.

Cependant, qui dit « performance », dit « mesure ». En effet, il est nécessaire de pouvoir :

connaître les paramètres de lancement de la JVM,
mesurer l’empreinte mémoire et le comportement du Garbage Collector,

En local…

Au fur et à mesure des différentes versions et afin d’obtenir les meilleures performances, la machine virtuelle Java (JVM) s’est dotée d’outils de diagnostic. Les principaux sont:

jps liste l’ensemble des JVM qui s’exécutent sur un système.

#jps -l
22791 weblogic.Server
18602 sun.tools.jps.Jps
5697 weblogic.Server
16937 activity.jar
6324 weblogic.Server

jstat affiche les statistiques d’une JVM sur sa gestion mémoire et le compilateur JIT.

#jstat -gcutil 16937 1s
  S0     S1     E      O      P     YGC     YGCT    FGC    FGCT     GCT
  0.00  99.96   0.00  89.53  33.10   1274   71.231   194   69.937  141.167
 83.53   0.00  65.48  77.26  33.10   1275   71.285   194   70.610  141.895
 83.53   0.00  75.30  77.26  33.10   1275   71.285   194   70.610  141.895
 83.53   0.00  84.44  77.26  33.10   1275   71.285   194   70.610  141.895
 83.53   0.00  96.26  77.26  33.10   1275   71.285   194   70.610  141.895
  0.00  99.77   0.00  90.35  33.10   1276   71.391   195   70.610  142.001
  0.00   0.00   4.87   0.73  33.11   1276   71.391   195   70.749  142.140
  0.00   0.00  10.18   0.73  33.11   1276   71.391   195   70.749  142.140
  0.00   0.00  29.65   0.73  33.11   1276   71.391   195   70.749  142.140

jconsole est une application graphique Swing qui affiche des informations sur la mémoire, les threads, les classes et les MBeans.

visualvm est également une application graphique qui reprend les informations affichées par JConsole mais en allant plus loin (ex: Détection de Contentions Thread). Livré avec le JDK de sun depuis la version JDK 6 update 7, VisualVM pourrait avec le temps remplacer complètement JConsole

visualgc affiche sous forme graphique les informations que l’on peut obtenir sur le garbage collector avec jstat. cette application n’est pas packagée avec la jvm, elle est disponible séparément avec les outils jvmstat. de plus, elle fonctionne avec les jvm 1.4.

Et à distance … ?

Par défaut, tous ces outils doivent être lancés sur la système d’exploitation où s’exécute la JVM à diagnostiquer. Cependant les contraintes de sécurité des entreprises interdisent parfois d’accéder physiquement à la machine. Dans le meilleur des cas, il est possible d’obtenir une connexion distante (Windows RDP, Telnet ou SSH), mais souvent avec des niveaux d’accréditations trop faibles pour pouvoir exécuter les commandes listées ci-dessus. Alors comment faire ?

Sun a pensé à tout. Si on regarde de prés une distribution d’une JVM, on remarque un binaire de type démon ‘jstatd’.

jstatd est un démon qui surveille la création et la destruction des JVM et fourni une interface qui permet à des outils distants de se connecter aux JVM qui s’exécutent sur la machine. Exactement ce qu’il nous faut, non ?

Le moyen le plus simple est d’exécuter jstatd de la façon suivante:

#nohup jstatd -J-Djava.security.policy=all.policy &
#cat all.policy
grant codebase "file:${java.home}/../lib/tools.jar" {
   permission java.security.AllPermission;
};
#

A partir de ce moment, il est possible d’utiliser les logiciels présentés ci-dessus.

jps, en précisant le nom de la machine distante. Noter l’apparition d’un nouveau processus java: sun.tools.jstatd.Jstatd

D:xebia-blog>jps -l myremoteserver
5697 weblogic.Server
28636 sun.tools.jstatd.Jstatd
22791 weblogic.Server
29726 activity.jar
6324 weblogic.Server

jstatd et visualgc en précisant le virtual machine identifier avec le format lvmid@servername

D:xebia-blog>jstat -gcutil 29726@myremoteserver 1s
  S0     S1     E      O      P     YGC     YGCT    FGC    FGCT     GCT
  0,00  99,78   0,00  83,38  33,14   8476  474,694  1227  445,801  920,495
  0,00  99,78   0,00  83,38  33,14   8476  474,694  1227  445,801  920,495
  0,00  78,41  77,46  42,98  33,14   8478  474,784  1227  446,133  920,917
 79,47   0,00  43,86  78,69  33,14   8481  474,971  1227  446,133  921,104
  0,00  82,64  76,48  63,39  33,13   8484  475,206  1228  446,649  921,855
  0,00  82,64  76,48  63,39  33,13   8484  475,206  1228  446,649  921,855
 85,47   0,00  77,78  74,92  33,13   8485  475,350  1228  446,649  921,999

Au lancement de visualvm, il suffit d’ajouter le nom du serveur ‘myremoteserver’ au noeud remote pour voir apparaître l’ensemble des JVM s’exécutant sur ce serveur. Il est possible alors de se connecter à l’une des machines virtuelles pour pouvoir avoir accès à:
Onglet Overview donne des informations générales (PID, Host, JVM Version, JVM Flags)

Onglet Monitor affiche des graphiques sur la consommation de ressources (Mémoire, Threads, …)

La copie d’écran suivante montre visualgc intégré sous forme de plugin dans visualvm

Cependant l’utilisation seule de jstatd n’est pas suffisante si l’on veut avoir accès aux MBeans JMX par jconsole et à l’activité des Threads avec visualvm. Il est nécessaire d’ajouter les paramètres suivants au démarrage de la JVM

-Dcom.sun.management.jmxremote.port=9999
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false

il est alors possible de connecter jconsole en utilisant la commande suivante:

D:xebia-blog>jconsole myremoteserver:9999

Avec l’outil visualvm, deux nouveaux onglets sont maintenant disponibles:

Onglet Threads affiche l’activité de l’ensemble des threads et permet d’obtenir facilement un thread dump

Onglet MBeans affiche l’ensemble des MBeans JMX

Conclusion

Vous êtes maintenant armés pour scruter votre application qui s’exécute dans votre JVM. Vouloir rendre votre application performante est une bonne idée. Cependant, l’expérience montre qu’il faut commencer absolument par analyser le code Java.
Exemple: Traitements inutiles ou redondants, accès à la base de données peu efficaces (trop ou pas assez de données manipulées),…
Il n’existe pas de paramètre magique dans la JVM (ou dans le Serveur d’application) qui permet à une application mal écrite de devenir performante.

Ce n’est que par la suite que l’on peut tuner la JVM. Si vous vous lancez dans cette aventure (passionnante) commencez par lire cet article de Kirk Pepperdine ,
My advice on JVM heap tuning, keep your fingers off the knobs!

Revue de Presse Xebia

Xebia France — Mon, 22 Sep 2008 16:50:51 +0000

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

Agilité

Discipline et agilité

Le coin de la technique

Agilité

Discipline et agilité

Dans cet article, Claude Aubry nous rappelle que l’agilité possède des règles à respecter. En effet nombreux sont ceux qui pensent que l’agilité permet de faire face aux imprévus plus rapidement. Ce n’est pas tout le temps le cas, car l’agilité possède des règles qu’il faut respecter (gestion du backlog, des priorités…) afin que les sprints se déroulent dans de bonnes conditions.

Le coin de la technique

Fragmentation mémoire et JVM, compactez votre ‘Gros Tas’

Si la description des différents algorithmes de Garbage Collection se trouve relativement facilement sur le Web, peu décrivent comment ceux-ci gèrent la fragmentation de la heap. Même si la durée de vie des objets est en moyenne très courte (dans une application de gestion), la JVM ne peut échapper à la gestion d’objets plus gros dont la durée de vie est plus importante. La fragmentation de la mémoire est inévitable. On estime que celle-ci peu atteindre facilement 10% de la mémoire pour des applications 24/7 et par conséquent peut être la cause d’OutOfMemory.
Dans son article Ghost in the Java Virtual Machine, Nick Maiorano nous décrit les différents mécanismes de compaction dont sont tirés ces grands principes.
Deux principes de compaction :

Garder une trace des fragments et les réallouer dès que c’est possible. Ceci implique le déplacement d’objets et la mise à jour des objets les référençant. Cette opération n’est rendue possible que lors d’un Full GC. Second problème, avec ce mécanisme, il se peut que deux objets créés simultanément se référençant l’un l’autre soient dispatchés sur deux pages physiques de la mémoire.
Copier les objets vivants dans une autre part de la mémoire en les agençant les uns après les autres. Avec cette méthode la mémoire est constamment réorganisée et les objets se retrouvent concentrés dans une même zone de la mémoire, ce qui peut améliorer les performances.

Nous vous laissons consulter le reste de l’article comparant le fonctionnement des algorithmes de compaction des JVM JRockit de BEA et Hotspot de Sun.

Indiscrétions sur Maven 2.1.0

Deux articles intéressants sur le blog de Brett Porter, commiteur Maven.
Un article sur la mise en ligne de Maven 2.1.0 milestone 1, avec une liste de quelques fonctionnalités qui seront ajoutées à cette version (en plus de meilleures performances).
Et un article sur le plugin reactor, qui apporte quelques fonctionnalités que l’on devrait retrouver intégrées de base à Maven 2.1. Le scénario suivant est donné en exemple: un build de 10 minutes plante au bout de 9 minutes à cause d’une erreur sur une dépendance. L’erreur est corrigée, et le plugin reactor permet de reprendre le build là où il a planté. Sympathique!

Améliorer les performances de Tomcat en production

La configuration par défaut de Tomcat répond à la plupart des besoins en production. Il est en outre facile de tuner légèrement le serveur d’application afin d’optimiser les performances de celui-ci.
Filip Hanik et Mark Thomas nous donnent quelques pistes dans leur Webinar hébergé par SpringSource.
Nous listerons ici les principaux faits marquants de cette optimisation, vus à travers 3 grands sujets (nous ne traiterons volontairement pas ici les optimisations de JVM, plus « convenues »).

Tuning des logs

Le fichier catalina.out de sortie de la console (java.util.logging.ConsoleHandler) a pour limitation de ne pas offrir de rotation. Il y a donc un risque d’overflow. On peut remplacer ce handler par un org.apache.juli.FileHandler (rotations quotidiennes) ou un java.util.logging.FileHandler (rotations par date ou au volume de fichier pour prévenir la saturation des disques).
Le logger par défaut est synchrone, ce qui peut devenir un goulet d’étranglement. L’utilisation d’un logger asynchrone peut donc améliorer les performances mais aucune implémentation n’est incluse dans Tomcat.

Tuning HTTP et TCP/IP
Avant de s’attaquer à ces améliorations, il est important de comprendre les protocoles TCP / IP, le fonctionnement du CPU et les concepts de load balancing.

Sessions TCP : Http Keep alive permet d’améliorer les temps de réponse en évitant quelques handshakes TCP ; cependant, l’accroissement de la consommation de ressources serveurs peut nuire aux sites à forte concurrence d’accès.
TCP Flow Control : bien que l’API Servlet repose sur des IO bloquantes, Tomcat optimise le service du contenu statique avec les connecteurs NIO et APR, grâce à la méthode non bloquante SEND_FILE.
Principaux paramètres à configurer :
     - maxThreads : typiquement entre 200 et 800, 400 étant une bonne valeur initiale.
     - maxKeepAliveRequests : typiquement entre 100 et 200 (SSL, APR / NIO connector) ou 1 pour désactiver « Keep Alive » (pas de SSL, BIO connector, très forte concurrence, etc).
     - acceptCount (backlog TCP) : typiquement entre 50 et 300.
     - connectionTimeout (SO_TIMEOUT), le temps maximum entre deux paquets TCP : entre 2000 à 3000 ms est souvent optimal, même en activant Keep Alive.

Quel connecteur choisir?
Cela dépend des besoins de l’application :

Blocking IO Connector :
     - La majorité du contenu est dynamique
     - Keep-Alive n’est pas important
     - La fiabilité est une priorité
Apache Portable Runtime/APR Connector :
     - Tomcat gère l’encryption SSL : l’implémentation SSL d’APR (Open SSL) est beaucoup plus rapide que celle des JVM et les handshakes SSL non bloquants améliorent les performances
     - Keep-Alive est important
     - Une grande partie du contenu est statique
     - La fonctionnalité Comet de Tomcat nécessite un connecteur non bloquant (APR ou NIO)
NIO Connector :
     - Connecteur non bloquant comme l’APR connector
     - A la différence de l’APR connector qui nécessite la librairie native APR, le NIO connecteur est portable sur toutes les plateformes
     - Le NIO connector ne bénéficie par de l’optimisation SSL apportée par Open SSL
AJP Connector :
- Déconseillé, il n’est pas plus performant que les connecteurs HTTP et est en revanche difficile à troubleshooter.

Dans le doute, utiliser le connecteur BIO (le plus mûr, qui ne crashera pas et qui auto gère le keep alive)

Contenu statique

Les connecteurs APR et NIO offrent l’optimisation SEND_FILE
Tomcat offre un cache (e.g. ) du contenu statique. Cependant, cette fonctionnalité ne rivalise pas avec un proxy cache comme Squid ou mod_cache )

Mockito s’offre un lifting.

Si vous appliquez les 10 commandements des tests unitaires (cf point 7), la sortie de la version 1.5 de Mockito devrait vous apparaître comme une bonne nouvelle.

Principale différence entre ce framework et ses concurrents (EasyMock et JMock), Mockito peut se passer d’expectations et vérifier le comportement d’un objet à posteriori. Cette fonctionnalité permet de considérablement réduire la taille du setup des tests, et de les rendre plus lisibles.

De plus, comme Mockito possède une syntaxe très similaire à celle d’EasyMock, il est facile de refactorer quelques tests pour l’essayer, et pourquoi pas l’adopter.

Java EE 6 et ses RI

Cette semaine, Antonio Goncalves, membre de l’expert group des JSR Java EE et co-fondateur du Paris Jug , nous rappelle l’arrivée prochaine de Java EE 6 début 2009 et récapitule la liste des principales implémentations de références des différentes briques et ses spécifications :

Spécifications	RI
EJB 3.1 Servlets 3.0	GlassFish V3
JPA 2.0	EclipseLink
Web Beans 1.0	JBoss Seam
JSF 2.0	Mojarra
JAX-RS 1.0	Jersey
JAX-WS 2.2	Metro

Une preview de Java EE 6 a d’ailleurs été effectuée ce mois-ci au Priceton JUG dont voici le résumé. Une session également en préparation au Paris JUG, elle est pour le moment prévue pour janvier prochain.

Des nouvelles de Java SE 7 …

Ah non, fausse alerte ! Point d’Umbrella JSR à l’horizon …

Revue de Presse Xebia

Xebia France — Mon, 15 Sep 2008 15:48:03 +0000

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

Le coin de la technique

Evènements de notre communauté en France et à l’étranger

Refactoring itératif de conférences : JavaPolis, Javoxx et DeVox

Le coin de la technique

`invokedynamic` vu de l’intérieur

Dans cet article, Charles Nutter, JRuby Core Developper nous présente pourquoi il est nécessaire de mettre à jour le bytecode invokedynamic.
Java nous oblige à typer chaque variable et chaque méthode doit définir une signature statique dont les types sont connus avant le Runtime : Java est un langage ‘statiquement’ typé. Si ce typage fort est une des forces du langage, comment la JVM peut-elle supporter des langages dynamiques ? La rigidité de Java provient, plus de son langage que de son bytecode. C’est ainsi que des langages comme Groovy permettent d’enfreindre certaines règles, par exemple : ne pas définir de types aux variables. Ce n’est pas pour autant que le bytecode va tout nous permettre, certaines règles sont incassables dont celles qui s’appliquent aux invocations de méthodes :

Les invocations sont statiquement typées.
Les invocations doivent s’effectuer sur des méthodes Java. Il est impossible de remplacer un appel à une méthode par un morceau de code interprété.

À l’origine, la JSR-292 a proposé la mise en place d’un nouveau code invokedynamic permettant l’invocation de méthodes sans signatures typées statiquement, mais rien n’avait été prévu pour modifier dynamiquement la logique d’invocation de la JVM.

Concurrency : past and present

Brian Goetz, auteur du livre ‘Java Concurrency In Practice’, a publié sur InfoQ une vidéo enregistrée lors du QCon 2007 : Concurrency : Past and Present.
Pourquoi est-il plus difficile de développer des applications multithreadées que de parler en lisant son journal ?
Dans cette présentation, Brian tente de répondre à cette question en revenant sur les principales difficultés de la programmation concurrente. Sujet que nous avions également abordé lors d’un article publié cet été sur le sujet : « programmation concurrente : notions fondamentales« . Pour illustrer ces problèmes, Brian revient sur l’histoire de la programmation concurrente et ses différentes approches, avant de donner ses recommandations. À la fin de la vidéo, il présente également les fonctionnalités offertes par d’autres langages comme ErLang et Scala.

Tuning des JVM Websphere 6.1

Giribabu Paramkusham et Ajay Bhalodia, WebSphere Application Server Technical Support, présentent dans JVM Performance Tuning with respect to Garbage Collection(GC) policies for WebSphere Application Server V6.1 part 1 (pdf) les points clef du tuning des JVM pour Websphere. Nous retiendrons :

Les JVM IBM proposent quatre stratégies de garbage collections :
     - -Xgcpolicy:optthruput pour minimiser le temps global d’exécution (batch, …).
     - -Xgcpolicy:optavgpause pour minimiser la durée de chaque pause.
     - -Xgcpolicy:gencon destiné aux applications web. L’algorithme Générationnel Concurrent communément utilisé dans les JVM Sun est optimisé pour les objets à courte durée de vie.
     - -Xgcpolicy:subpools pour les serveurs à grand nombre de processeurs (>16).
A la différence de l’implémentation GenCon de Sun qui comprend trois zones (Young, Tenurd et Permanent), celle d’IBM n’en comporte que deux (Young et Old)
L’option -verbose:gc est activable en production avec un impact négligeable sur les performances et l’option moins connue -Xverbosegclog permet de préciser un fichier de sortie en mode rolling file . Nous noterons que les informations de GC sont désormais formattées en XML ce qui facilitera la manipulation avec des outils.
Indépendamment des limites techniques liées au système d’exploitation, les JVM IBM sont optimisées pour utiliser des heap le plus souvent inférieures à 2 GB :

Platform	Additional Options	Maximum Possible	Advised Maximum
AIX	automatic	3.25 GB	2.5 GB
Linux		2 GB	1.5 GB
	Hugemem Kernel	3 GB	2.5 GB
Windows		1.8 GB	1.5 GB
	/3GB	1.8 GB	1.8 GB
z/OS		1.7 GB	1.3 GB

source IBM

L’utilisation de JVM 64 bits supprime les limites de taille de heap mais pénalisent les performances (plus de données manipulées) et la consommation mémoire (des pointeurs sur 64bits plutôt que 32bits accroissent de 30% à 50% la mémoire consommée)
La JVM 6 d’IBM réduit les dégradations de performances et de consommation mémoire en 64bits grâce à l’introduction de « pointeurs compressés »

Performance d’affichage d’une page Web

Hayes Potter, nous présente dans Speed up your website, quick! des règles structurantes afin d’améliorer les performances d’affichage d’une page Web :

Compression des ressources statiques (images, fichiers flashs, scripts, …).
Mettre en place une politique d’expiration des ressources statiques .
Mettre les styles CSS en haut de la page HTML tandis qu’il faut mettre les fichiers Javascript en bas de la page.
Limiter les requêtes http://request vers d’autres domaines. En effet à chaque requête vers un autre domaine, pendant le chargement de la page, une résolution DNS est effectué (accès réseaux supplémentaires).

Dans le même esprit, Yahoo a mis à dispositon de la communauté des développeurs Web un ensemble de règles : Exceptional Performances.
Il y a 34 Best Pratices répartis dans 7 domaines différents :

Contenu
Serveur
Cookie
CSS
Javascript
Image
Mobile

Voici les règles les plus marquantes :

Externaliser les fichiers CSS et Javascripts de la page HTML.
Réduire la taille des fichiers Javascripts en éliminant les caractères superflus (espace, variable à rallonge, …). Cela peut être assisté par des outils tel que JSMin et YUI Compressor. L’idéal c’est que les développeurs des pages gardent des fichiers Javascripts lisibles et maintenables puis au déploiement de ces pages, passer une moulinette sur les fichiers Javascripts afin d’épurer les caractères superflus.
Eviter la duplication des importations du même script, par exemple IE retéléchargera plusieurs le fichier bien que c’est la même ressource.
Utiliser une requête HTTP GET pour les requêtes AJAX.
Rassembler l’ensemble de vos images (pour les gestions des boutons par exemple) en une seule image et en faire un sprite avec CSS. Cette tache peut être assister par les outils CSS Sprites et Website Performance CSS Sprite Generator.
Limiter l’utilisation des iframe.

Références :

Yahoo! New Performance Best Practices Now Available (Mars 2008), excellente présentation de Stoyan Stefanox, développeur Yahoo, qui reprend point par point toutes ces Best Pratices

Voici une liste d’outils facilitant la mise en oeuvre et la vérification de ces points :

YSlow, outil Yahoo aidant à la vérification de ces best pratices
Fiddler, debugger HTTP
IBM Page Detailler, décrire le déroulement des fichiers téléchargés pour l’affichage d’une page
Firebug (que pour firefox)
JSMin, minimiseur JavaScript
YUI Compressor, minimiseur Javascript
CSS Sprites, générateur de sprite CSS
Website Performance CSS Sprite Generator, générateur de sprite CSS

Evènements de notre communauté en France et à l’étranger

Refactoring itératif de conférences : JavaPolis, Javoxx et DeVox

Terminons cette revue de presse par la petite histoire belge de la semaine. L’un des plus gros événements Java au monde JavaPolis vient de changer de nom pour la seconde fois cette année. Renommé Javoox en début d’année, il semblerait que cet ancien nouveau nom soit encore trop proche de « Java » pour Sun. Avec ce nouveau nom : DeVoxx, le BeJug (porteur de l’événement) continue le bras de fer avec Sun en osant mettre un ‘V’ en 3e caractère de leur nouveau nom … tout comme dans ‘jaVa’ … La newsletter de DeVoxx nous explique que ce nouveau changement de nom est dû à une volonté de rester un événement Java indépendant.

Site officiel du BeJug
Site officiel du DeVoxx
Consultez la liste des intervenants à DeVoxx 2008

Revue de Presse Xebia

Xebia France — Mon, 21 Jul 2008 16:45:01 +0000

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

Actualité éditeurs / SSII

Dur dur d’être un (Java)Rebel

RIA

Vidcast de Christophe Coenraets autour de Flex

Le coin de la technique

Actualité éditeurs / SSII

Dur dur d’être un (Java)Rebel

S’il n’est pas simple de faire connaître un outil, il est encore plus compliqué de le monétiser. ZeroTurnaround nous en fait la démonstration avec JavaRebel. C’est la fête à la licence : après les dons aux ceintures marrons de Java Black Belt, et aux membres de projets open-source, ZeroTurnaround offre cette fois ses licenses aux lecteurs de DZone (digg-like pour développeurs). Quelle sera la prochaine étape ? La gratuité pour les usages non commerciaux ?

JavaRebel est agent java permettant de recharger à la volée des modifications effectuées sur classes. A l’utilisation, le principe reste le même que celui du hotswap proposé out-of-the-box par la JVM Sun, offrant un rechargement plus complet.

RIA

Vidcast de Christophe Coenraets autour de Flex

A ceux qui ont raté James Ward au Paris JUG, InfoQ offre une seconde chance avec l’interview de Christophe Coenraets, lui aussi évangéliste Adobe, captée dans le cadre du QCon 2008 de Londres.
Dans cette vidéo, Christophe Coenraets aborde les points suivants :

Les technologies RIA Abode : Flex 3, Air et BlazeDs
L’environnement de développement d’abode, FlexBuilder 3
La stratégie open-source d’Adobe
L’introduction d’un front-end Flex dans un SI existant
L’avenir des RIA à travers leur intégration aux moteurs de recherche et aux navigateurs internet

Une bonne façon de se remettre rapidement à jour si vous avez raté les derniers développements de la percée d’Adobe sur le marché des clients riches.

Le coin de la technique

Failles de sécurité dans Spring MVC

La nouvelle est assez rare pour que tout le monde s’en empare (TSS, techtarget, net-security.org, xtremeopensource.org, linux mag, …), Ounce Labs annonce la découverte de problèmes dans Spring MVC pouvant causer des failles de sécurité dans les applications utilisant ce framework, en voici les descriptions :

Soumission de champs de formulaire non éditables. Si votre modèle contient plus de champs que votre formulaire HTML, il est possible d’envoyer une fausse requête contenant des données non éditables.
Injection Modèle/Vue. Ce problème arrive lorsque le rendering utilise un nom de vue provenant directement d’une requête. Si ces noms mappent certaines ressources protégées par le serveur d’applications, il est alors possible, dans certains cas, d’y accéder.

Ces deux vulnérabilités sont connues depuis longtemps par Spring Source, qui vient de publier une Spring MVC vulnerability FAQ à ce sujet. Il ne s’agit pas de véritables bugs, mais plus d’un mauvais usage du framework. Cela ressemble plus à une opération publicitaire de Ounce Labs qu’à une véritable alerte ; ce coup d’éclat a tout de même le mérite de nous rappeler la difficulté des développements web et le dilemme permanent des frameworks web qui sont écartelés entre l’ajout de fonctionnalités et la sécurité. Les approches actuelles zéro-confs sont à ce titre bien dangereuses.

Premier résultat SpecJVM2008, et alors ?

David Dagastine annonce dans First SPECjvm2008 Result Published! que Sun a publié le premier résultat de ce benchmark de JVM. Cependant, nous pouvons nous interroger sur le rôle qu’a aujourd’hui un tel benchmark dans le choix d’une JVM alors que les machines virtuelles d’IBM (J9), d’Oracle-BEA (Jrockit) et de Sun (Hotspot) qui ont aussi bonne presse sur ce sujet. Le critère de l’exploitabilité de la JVM, aujourd’hui très en vogue avec la médiatisation de VisualVM (Sun), ne semble pas plus pris en compte aujourd’hui alors que des écarts importants subsistent entre les éditeurs et qu’Oracle-BEA a de sérieux atouts différenciant avec son très mature JRockit Mission Control.

En fait, les JVM sont devenues des commodités et le critère de choix relève aujourd’hui plus de l’écosystème et particulièrement du serveur d’applications Java. Un utilisateur de Websphere devra utiliser J9 [1], un utilisateur de Weblogic aura le choix entre JRockit et Hotspot et les autres utilisateurs (Tomcat, JBoss, etc) se tournent le plus souvent vers le standard de facto : l’implémentation de Sun.

Nous noterons un point intéressant sur SpecJVM2008 : le benchmark se fait sans aucun tuning de la JVM. Cette règle illustre la tendance actuelle des éditeurs de JVM qui fournissent des machines virtuelles optimales en configuration par défaut grâce à des mécanismes de détection de la configuration de l’OS et d’optimisation automatique à l’exécution.

[1] sauf sur les plateformes sur lesquelles IBM n’a pas porté J9 et où il propose alors Hotspot (Solaris, HP UX)

Envers : JBoss ajoute à JPA le versioning des données

Trois mois après l’annonce d’une preview, Adam Warski propose aujourd’hui la version 1.0 de JBoss Envers, une extension à JPA pour versioner les données, un sujet fréquent dans l’informatique de gestion des contrats. L’occasion pour JBoss de réaffirmer sa place de leader de l’innovation autour de JPA.

Les points clefs de JBoss Envers :

Versioning de propriétés simples (strings, integers, longs…) comme des composants embedded (eux même composés de propriétés simples)
Versioning de classes aux ids simples, composites ou _embedded_
Versioning des relations one-to-one et one-to-many
Listener de révision @RevisionEntity pour notamment ajouter des modifications spécifiques aux entités versionées
Historisation par numéro de version (@RevisionNumber) ou à date (@RevisionTimestamp)
Requête sur les données historiées avec un VersionsReader
Envers repose sur l’EntityManager JPA plutôt que la Session Hibernate, on peut y voir un signe supplémentaire pour migrer des API propriétaires d’Hibernate vers celles standard de JPA.

Exemple de classe versionnée avec Envers :

@Entity
@RevisionEntity(MyRevisionListener.class)
public class Person {
    @Id
    @GeneratedValue
    Integer id;
    @Versioned
    String name;
    @Versioned
    String surname;
    @Versioned
    @ManyToOne
    Address address;
    @RevisionTimestamp
    long revisionTimestamp;
   ...
}

Pour plus d’informations sur ce sujet, nous aimons Patterns for things that change with time de Martin Fowler.

JSR 203: More New I/O APIs for the Java Platform (« NIO.2″)

Si NIO 1 mettait l’accent sur la scalabilité, JSR 203 – NIO 2 se focalisera sur l’utilisabilité des différents systèmes de fichiers comme Alan Bateman (Sun) et Carl Quinn (Google) l’ont expliqué à JavaOne dans « New I/O in JDK 7″. Les points clefs de NIO 2 :

Nouvelle API d’abstraction de système de fichier (FileSystem, Path / FileRef et FileStore) et notamment l’amélioration de la navigation dans les arborescences.
Unification des API Channel et Socket avec une abstraction système de fichier sous-jacent.
Amélioration des I/O asynchrones.
Correction de bugs qui trainaient de longue date des les API I/O

Dans la continuité, Elliotte Rusty Harold détaille dans The Open Road: java.nio.file le fonctionnement de la nouvelle abstraction du système de fichier.

Pour plus d’informations sur les nouveautés de Java 7 :

L’avenir de la virtualisation et du cloud computing java selon Billy Newport

Billy Newport, Websphere eXtreme Scale, explique dans une interview à Floyd Marinescu, InfoQ sa vision de la virtualisation et du cloud computing en Java.

Nous retiendrons :

Pour les applications Java, la virtualisation de la couche physique (processeur, mémoire, etc) tend vers la gestion de grappes de petits serveurs virtuels à ressources fixes (e.g. 4 ways, 2 Go de RAM, 160 Go de disque) plutôt que vers des serveurs de grande capacité à ressources variables : il est très difficile d’optimiser les performances de gros serveurs (e.g. 32+ cores/ways, 10+ Go de RAM, etc) et les programmes ont le plus grand mal à se réadapter (e.g. pool de threads, taille de cache) quand les ressources allouées changent
Des serveurs à plusieurs dizaines de cores arriveront plus vite que nous le pensons et les éditeurs de JVM s’y préparent, mais les JVM et les APIs de concurrence ne sont aujourd’hui pas prêtes. Par exemple, les pattern multi-reader/mono-writer ne seront plus adaptés.
Les grilles de données n’ont pas besoin d’API spécifiques pour le moment : JPA et JMS suffisent aux besoins actuels. Par ailleurs, l’API JSR-107: JCache suscite des réticences de la part des grands éditeurs de grilles java et ne verra probablement jamais le jour.
La virtualisation des données se divise en deux grande familles :
- Network Attached Cache : le paradigme de programmation est le même qu’en l’absence de cache. Typiquement positionné en cache L2 d’un framework JPA, les données du cache sont rapatriées sur le serveur d’applications pour réaliser les traitements métiers, mais ce modèle atteint ses limites avec le coût de rapatriement des données.
- eXtreme Transaction Processing Grid : le paradigme de de programmation change complètement ; le traitement métier, au lieu d’être réalisé sur le serveur d’applications, est envoyé sur tous les noeuds de la grille, seule la consolidation est effectuée sur le serveur d’applications. Cette architecture scale jusqu’à plusieurs milliers de noeuds sur la grille.
Les SGBD, avec la co-localisation des données, ont atteint leur limite de scalabilité. IBM comme Oracle ou Microsoft investissent aujourd’hui dans les data grids pour lever cette limite (respectivement eXtreme Scale, Coherence et Velocity).

GC générationnels traditionnels (jdk6) VS GC Garbage First (jdk7)

Erwan Alliaume — Wed, 12 Mar 2008 07:28:56 +0000

L’analyse empirique montre que dans une application la très grande majorité des objets créés sont détruits presque immédiatement. C’est d’autant plus vrai pour les applications web et/ou stateless où la plupart des objets sont créés pour traiter une requête et peuvent être donc détruits juste après ce traitement. De ce constat résulte l’idée de ne pas traiter de la même façon les objets fraîchement créés et ceux qui existent depuis plus longtemps. Les Garbage Collector qui utilisent des implémentations basées sur ce principe sont appelés GC générationnels. On peut fixer deux catégories d’objectifs lorsque l’on optimise le GC : réduire les pauses ou augmenter le débit. Ces objectifs sont en général orthogonaux (la réduction de la durée des pauses se fait au détriment du débit, et vice-versa), ils dépendent souvent du type d’applications : dans une application interactive, nous privilégierons les pauses, et au contraire, dans un batch, seul le débit compte.

La suite du billet est décomposée en deux parties :

La première décrit le fonctionnement des algorithmes générationnels traditionnels (Implémentation actuelle des JVM Sun)
La seconde détaille le nouvel algorithme que Sun essaye de pousser pour sa future JVM

GC Générationels

Avant de présenter la nouvelle implémentation que Sun essaye de mettre en avant pour le jdk 7, décrivons le cycle de vie des objets dans le tas (heap) tel qu’il est actuellement implémenté dans les JVM Sun. Le « heap » se compose de trois sections principales « Young », « Tenured » et « Perm ». Au cours de sa vie, un objet est amené à évoluer au sein de ces zones en fonction de son ancienneté, à chaque section correspond une génération d’objet.

Les nouveaux objets sont stockés dans une première zone de la « young generation » appelée « l’eden » (1). Lorsque cette zone est remplie, le garbage collector analyse les objets présents dans cette zone et nettoie les objets devenus inutiles (ne possédant plus de références).

Les objets ayant résisté à ce passage sont placés dans une seconde partie appelée « survivor » (2). Il s’agit d’une zone intermédiaire contenant les objets les plus vieux de la « young generation ». L’eden ayant été vidée lors du passage du GC, de nouveaux objets peuvent faire leur apparition dans cette même zone. À ce moment deux zones contiennent alors des objets : l’eden et le survivor. Dès lors, lors des futurs passages du GC, ces deux zones seront analysées et les objets toujours en activité seront placés dans une 2e zone « survivor ». Les deux zones « survivors » sont utilisées alternativement par le GC pour stocker les objets utilisés.

Avant que ces zones ne deviennent également trop petites et lorsqu’un objet est considéré comme assez âgé, il est déplacé dans la deuxième génération : « tenured » (3). Il s’agit d’un emplacement permettant de stocker les objets les plus anciens. Lorsque cette zone est remplie, le garbage collector effectue un nettoyage en profondeur des différentes zones et générations : le full GC. Si après un full GC l’espace disponible n’est pas suffisant pour gérer la vie de l’application, une exception est levée : java.lang.OutOfMemoryException.

Quant à la troisième section : « la perm », celle-ci stocke les objets n’ayant pas besoin d’être nettoyés par le GC, comme les classes chargées par le class loader lors de l’exécution d’un programme. Ces objets resteront disponibles pendant toute la durée de vie de la JVM. De la même manière, cette zone n’étant jamais nettoyée, si celle-ci vient à saturer, un OutOfMemory est également lancé : « java.lang.OutOfMemoryError: PermGen space » . Son fonctionnement est donc un peu différent : il n’y a pas de promotion dans cette zone.

Les zones « virtual » ne sont pas utilisées par la machine virtuelle pour stocker des données. Elles correspondent à l’écart entre la taille réelle et la taille max. Leur réservation n’a pas encore été faite auprès système. Elles n’existent que si on a choisi une taille adaptative (Taille Heap Min (-Xms) < Taille Heap Max (-Xmx)).

Pour résumer, les objets sont créés dans « l’eden » (1), puis déplacé dans le « survivor » (2) puis dans le « Tenured » (3).

Le GC effectue deux types de traitements :

Un nettoyage rapide lorsque « l’eden » est rempli, comme il s’agit d’un algorithme de copie, la destruction d’un objet ne coûte rien : zéro inscrution \! Traitement parallélisable.
Un nettoyage approfondi, plus gourmand en ressources, lorsque le « tenured est saturé ». Il faut libérer la mémoire explicitement, et éventuellement la compacter (donc déplacer les objets et mettre à jour les références en conséquence) Plusieurs algo disponibles : Mark&Sweep, Concurrent Mark&Sweep, Incremental/train

L’un des objectifs de l’optimisation du GC est donc de limiter la fréquence des FullGC en s’assurant que le maximum d’objets sera ramassé avant sa promotion dans la old génération. Pour une application web, cela signifie généralement que l’intervalle entre 2 fullGC est supérieur au temps de traitement max d’une requête. Rappelons en passant que la méthode System.gc() déclenche un FullGC et devrait la plupart du temps être proscrite (-XX:+DisableExplicitGC)

GC Garbage First

L’idée de l’algorithme G1 (Garbage-First) est d’utiliser les spécificités des environnements multiprocesseurs afin d’approcher des performances ‘temps réel’ tout en maintenant un débit élevé. Pour parvenir à ce but, le tas n’est plus divisé en générations, mais en un nombre beaucoup plus grand de petites régions. Désormais, la collecte d’une génération dans son ensemble n’est maintenant plus obligatoire, elle peut se limiter à un ensemble précis de régions.

La sélection de ces régions est possible grâce à un marquage spécifique : snapshot-at-the-beginning (SATB). Ce marquage, concurrent et très rapide, fournit au GC une analyse périodique et exhaustive de l’utilisation des différents objets en mémoire. Toutes les références des différents objets sont suivies. Leur examen permet la détection des objets qui ne sont plus utilisés : ils sont alors considérés comme déchets.

Un ensemble de métrique est également maintenu afin de permettre d’évaluer l’occupation des différentes régions du tas : taille maximale de la région, ancienneté, pourcentage d’occupation et surtout, pourcentage de déchets. De plus, les collectes passées permettent au GC de connaître relativement précisément le coût de la collecte d’une région particulière. En croisant ces évaluations (probabilités) avec le recensement des références dans les régions du système, le GC peut effectuer une sélection arbitraire d’un ensemble de régions nettoyable durant une période prédéfinie. La configuration du GC permet à l’utilisateur de spécifier une fraction de temps maximale consacrée à la collecte (par exemple : sur 100 secondes d’exécution de l’application, le nettoyage des données ne peut pas dépasser 5 secondes (5%)), ce qui revient presque à définir les horaires des collectes par configuration. Les régions privilégiées sont celles qui possèdent les données les plus jeunes et le plus de déchets, car elles proposent généralement un meilleur rendement : voici donc d’où vient le nom de l’algorithme « Garbage First ». Cette sélection de régions peut être considérée comme une young génération dont le contenu est défini dynamiquement : Garbage First est donc un algorithme générationnel. Par ailleurs, afin d’éviter de dépasser ce temps ‘objectif’, et donc pour d’optimiser le débit, la collecte peut-être reportée si nécessaire (dans la mesure du possible), peut être qu’au prochain passage plus de déchets seront présents dans une des régions.

Illustrons ces propos par un exemple :

Supposons que le tas est découpé en 12 régions. Les zones vertes sur les schémas suivants représentent des régions vides.

Le marquage a été effectué, il en résulte le découpage suivant. Le pourcentage affiché dans chacune des cases ci-dessous correspond au pourcentage d’objets vivants dans leur région associée. Ainsi dans la 2e case, 3% des objets présents dans celle-ci sont toujours utilisés, par conséquent cette région possède 97% de déchets. Les régions qui ne comptent pas d’objets vivants sont entièrement libérées. La collecte de zone ne contenant que des déchets est très rapide, on peu le comparer à celui utilisé dans les ‘survivor’ dans les algorithmes générationnels traditionnels.

L’application continue de tourner autant de temps que nécessaire pour remplir une nouvelle région intégralement : les nouveaux objets sont référencés dans une même région (case orange). Si un cycle de collection n’est pas suffisant pour remplir cette région, le GC ne se lance pas.

Maintenant que cette nouvelle région est remplie, le GC sélectionne les régions les contenant le plus de déchets qu’il estime pouvoir traiter simultanément (GabageFirst !). Les données vivantes restant dans ces régions sont copiées et rassemblées dans une autre région. Comme il s’agit d’un algorithme de copie, très peu de temps est nécessaire à l’exécution de cette tâche. Une fois que la copie terminée, les zones sélectionnées ne contiennent plus d’objets vivants, elles sont alors collectées.

Au final, si on récapitule, les avantages avancés de ce nouvel algorithme sont les suivants :

Meilleure prédiction des temps de pauses destinées au GC.
Courte pause sans fragmentation.
Nettoyage acceptant la parallélisassions et la concurrence.
Meilleure utilisation du tas.

En plus d’améliorer le débit des collectes, comme le tas n’est pas divisé en générations, les problèmes de sizing des différentes générations ne sont plus d’actualité : fini les prises de tête avec le calcul des ratios young / tenured générations.

Informations complémentaires à propos de ce nouvel algorithme :