Catégorie : Sun

Deux nouvelles

Ce fait longtemps que je n’ai pas fais de billet. Je suis un peu occupé en ce moment, mais cela va se calmer (du moins je l’espère).

Deux nouvelles :

  • La première c’est que la version 9.04 de Ubuntu devrait sortir dans deux jours (le 23 avril). Ce n’est pas une nouveauté si vous suivez (ou utilisez) Ubuntu… Enfin toujours est-il que j’utilise la beta et maintenant la RC depuis 3 semaines.
    On est passé à OpenOffice.org 3.0.1 qui permet entre autre de faire des beaux tableaux dans une diapositive Impress, cela n’existait pas dans la 2.4, et c’est très pratique dans ses présentations (Powerpoint le proposait depuis un bout de temps).
    Par ailleurs le temps de démarrage (boot) est optimisé. Pour moi ce n’est pas flagrant sur mon poste, mais on le ressent.
    La liste des (grosses) nouveautés est visible ici
  • La deuxième nouvelle c’est l’achat de Sun par Oracle. Cela donne quelques frissons quand à l’avenir de Java, MySQL ou bien OpenOffice.org, sans parler de NetBeans, OpenSolaris et les serveurs Sun.
    Avec Sun+Oracle on obtient quelque chose qui ressemble à IBM. Est-ce que cela sera une bonne chose ? Merci qui ? merci la crise…

./

SAP Memory Analyzer : voilà un vrai outil pour analyser des Heap Dump Java !

Vous avez développé une application JEE, et depuis son passage en production au moins une fois par jour il y a une erreur Java « OutOfMemoryError ». La première réaction a été de dire : mauvaise configuration de la taille maximale de la JVM… vous avez préconisé 1Go de Max Heap Size, cela n’a pas fonctionné, l’erreur OOME arrive encore… Alors on est passé à 2Go… Toujours l’erreur d’OOME… Aie, et que faire…

Quand vous êtes à ce point, vous pouvez être certain que vous avez une fuite de mémoire (memory leaks) quelque part. Oh, ce n’est pas que vous êtes un mauvais développeur 😉 et que vous ne savez pas bien gerer la mémoire, en effet, parfois un problème de fuite de mémoire peut survenir à cause d’une fonctionnalité activée du serveur d’applications de production et qui rentre en « conflit » avec une brique de l’application. (Je citerai un exemple vécu : le cache (activé) JDBC de la source de données WebSphere 5.1 et un framework maison de mapping O/R)

Quand on a un problème d’OutOfMemory, on commence souvent par activer le mode verbeux du Garbage Collector (GC), c’est une très bonne idée, cela permet d’avoir une petite idée sur le déroulement du problème de mémoire (on peut utiliser l’outil Extensible Verbose Toolkit d’IBM pour ce travail, cf références). Cependant c’est insuffisant pour trouver la cause du problème. Quelques recherches sur Internet vous apprennent qu’il est possible d’avoir une image de la mémoire Java avec la génération d’un « heap dump », ensuite il suffit de l’analyser pour trouver la cause de la fuite de mémoire. Facile à écrire, mais dur à faire…

Continuer la lecture de SAP Memory Analyzer : voilà un vrai outil pour analyser des Heap Dump Java !