La fonctionnalité permet donc de mieux comprendre le déroulement d’un traitement, en particulier lors qu’un problème survient lors d’un tir de charges ou sur un environnement en production. Et imaginons que ce problème ‘ne se reproduit pas’ en environnement de recette / développement, et donc l’origine pourrait être ces accès multiples en même temps…

Un développeur seul sur sa machine génère que un seul log séquentiel, mais avec de multiples utilisateurs, le log devient un enchevêtrement de plusieurs traitements séquentiels.

Voici un exemple de log applicatif pendant un tir de charges :

[2008-01-15 20:31:50,750][DEBUG] (DaoBoxers.java:24) - bdSelectAll() - SQL => SELECT ID, PRENOM, NOM FROM BOXERS
[2008-01-15 20:31:50,755][DEBUG] (DaoBoxers.java:27) - bdSelectAll() - ResultSet ok => org.apache.tomcat.dbcp.dbcp.DelegatingResultSet@1ba287e
[2008-01-15 20:31:50,757][DEBUG] (DaoBoxers.java:36) - bdSelectAll() - Retour list
[2008-01-15 20:31:50,758][DEBUG] (JndiJdbcTableView.java:62) - doGet() - Mise en attribut resultat
[2008-01-15 20:31:50,758][DEBUG] (JndiJdbcTableView.java:64) - doGet() - Renvoi vers JSP
[2008-01-15 20:31:50,759][DEBUG] (JndiJdbcTableView.java:78) - doGet() - end
[2008-01-15 20:31:50,768][DEBUG] (JndiJdbcWithValidationTableView.java:48) - doGet() - start
[2008-01-15 20:31:50,769][INFO ] (JndiJdbcWithValidationTableView.java:56) - doGet() - Ok connexion
[2008-01-15 20:31:50,769][DEBUG] (JndiJdbcWithValidationTableView.java:60) - doGet() - Appel Boxers => bdSelectAll
[2008-01-15 20:31:50,770][DEBUG] (DaoBoxers.java:24) - bdSelectAll() - SQL => SELECT ID, PRENOM, NOM FROM BOXERS
[2008-01-15 20:31:50,775][DEBUG] (DaoBoxers.java:27) - bdSelectAll() - ResultSet ok => org.apache.tomcat.dbcp.dbcp.DelegatingResultSet@1d2f8be
[2008-01-15 20:31:50,776][INFO ] (DirectJdbcTableView.java:60) - doGet() - Ok connexion
[2008-01-15 20:31:50,777][DEBUG] (DirectJdbcTableView.java:64) - doGet() - Appel Boxers => bdSelectAll
[2008-01-15 20:31:50,777][DEBUG] (DaoBoxers.java:24) - bdSelectAll() - SQL => SELECT ID, PRENOM, NOM FROM BOXERS
[2008-01-15 20:31:50,775][INFO ] (DirectJdbcTableView.java:60) - doGet() - Ok connexion
[2008-01-15 20:31:50,778][DEBUG] (DirectJdbcTableView.java:64) - doGet() - Appel Boxers => bdSelectAll
[2008-01-15 20:31:50,778][DEBUG] (DaoBoxers.java:24) - bdSelectAll() - SQL => SELECT ID, PRENOM, NOM FROM BOXERS
[2008-01-15 20:31:50,780][DEBUG] (DaoBoxers.java:36) - bdSelectAll() - Retour list
[2008-01-15 20:31:50,780][DEBUG] (JndiJdbcWithValidationTableView.java:62) - doGet() - Mise en attribut resultat
[2008-01-15 20:31:50,780][DEBUG] (JndiJdbcWithValidationTableView.java:64) - doGet() - Renvoi vers JSP
[2008-01-15 20:31:50,783][DEBUG] (JndiJdbcWithValidationTableView.java:78) - doGet() - end
[2008-01-15 20:31:50,784][DEBUG] (DaoBoxers.java:27) - bdSelectAll() - ResultSet ok => com.mysql.jdbc.ResultSet@10de02d
[2008-01-15 20:31:50,786][DEBUG] (DaoBoxers.java:36) - bdSelectAll() - Retour list
[2008-01-15 20:31:50,786][DEBUG] (DirectJdbcTableView.java:66) - doGet() - Mise en attribut resultat
[2008-01-15 20:31:50,787][DEBUG] (DirectJdbcTableView.java:68) - doGet() - Renvoi vers JSP
[2008-01-15 20:31:50,788][DEBUG] (DirectJdbcTableView.java:85) - doGet() - end
[2008-01-15 20:31:50,789][DEBUG] (DaoBoxers.java:27) - bdSelectAll() - ResultSet ok => com.mysql.jdbc.ResultSet@172c403
[2008-01-15 20:31:50,786][INFO ] (DirectJdbcTableView.java:60) - doGet() - Ok connexion
[2008-01-15 20:31:50,791][DEBUG] (DirectJdbcTableView.java:64) - doGet() - Appel Boxers => bdSelectAll
[2008-01-15 20:31:50,791][DEBUG] (DaoBoxers.java:24) - bdSelectAll() - SQL => SELECT ID, PRENOM, NOM FROM BOXERS
[2008-01-15 20:31:50,792][DEBUG] (JndiJdbcWithValidationTableView.java:48) - doGet() - start
[2008-01-15 20:31:50,792][INFO ] (JndiJdbcWithValidationTableView.java:56) - doGet() - Ok connexion
[2008-01-15 20:31:50,793][DEBUG] (JndiJdbcWithValidationTableView.java:60) - doGet() - Appel Boxers => bdSelectAll
[2008-01-15 20:31:50,793][DEBUG] (DaoBoxers.java:24) - bdSelectAll() - SQL => SELECT ID, PRENOM, NOM FROM BOXERS
[2008-01-15 20:31:50,794][DEBUG] (DaoBoxers.java:36) - bdSelectAll() - Retour list
[2008-01-15 20:31:50,794][DEBUG] (DirectJdbcTableView.java:66) - doGet() - Mise en attribut resultat
[2008-01-15 20:31:50,795][DEBUG] (DirectJdbcTableView.java:68) - doGet() - Renvoi vers JSP
[2008-01-15 20:31:50,796][DEBUG] (DirectJdbcTableView.java:85) - doGet() - end
[2008-01-15 20:31:50,798][DEBUG] (DaoBoxers.java:27) - bdSelectAll() - ResultSet ok => org.apache.tomcat.dbcp.dbcp.DelegatingResultSet@695586
[2008-01-15 20:31:50,799][DEBUG] (DaoBoxers.java:36) - bdSelectAll() - Retour list

La fonctionnalité NDC ajoute la possibilité d’avoir un « identifiant » de traitement, par exemple le nombre de secondes depuis le 1er janvier 1970. Ainsi le log devient un enchevêtrement de traitements séquentiels identifiés.
Et voici un exemple de log applicatif avec NDC :

[2008-01-15 20:07:55,920][DEBUG] (DaoBoxers.java:27) - bdSelectAll(1200427675911) - ResultSet ok => org.apache.tomcat.dbcp.dbcp.DelegatingResultSet@19e907
[2008-01-15 20:07:55,921][DEBUG] (DaoBoxers.java:36) - bdSelectAll(1200427675911) - Retour list
[2008-01-15 20:07:55,922][DEBUG] (JndiJdbcWithValidationTableView.java:62) - doGet(1200427675911) - Mise en attribut resultat
[2008-01-15 20:07:55,922][DEBUG] (JndiJdbcWithValidationTableView.java:64) - doGet(1200427675911) - Renvoi vers JSP
[2008-01-15 20:07:55,924][DEBUG] (DaoBoxers.java:27) - bdSelectAll(1200427675917) - ResultSet ok => org.apache.tomcat.dbcp.dbcp.DelegatingResultSet@93a96c
[2008-01-15 20:07:55,925][DEBUG] (DaoBoxers.java:36) - bdSelectAll(1200427675917) - Retour list
[2008-01-15 20:07:55,926][DEBUG] (JndiJdbcWithValidationTableView.java:62) - doGet(1200427675917) - Mise en attribut resultat
[2008-01-15 20:07:55,926][DEBUG] (JndiJdbcWithValidationTableView.java:64) - doGet(1200427675917) - Renvoi vers JSP
[2008-01-15 20:07:55,927][DEBUG] (JndiJdbcWithValidationTableView.java:78) - doGet(1200427675911) - end
[2008-01-15 20:07:55,929][DEBUG] (DirectJdbcTableView.java:49) - doGet(1200427675929) - start
[2008-01-15 20:07:55,931][DEBUG] (JndiJdbcWithValidationTableView.java:78) - doGet(1200427675917) - end
[2008-01-15 20:07:55,934][DEBUG] (DirectJdbcInInitTableView.java:49) - doGet(1200427675934) - start
[2008-01-15 20:07:55,938][DEBUG] (JndiJdbcWithValidationTableView.java:48) - doGet(1200427675938) - start
[2008-01-15 20:07:55,938][INFO ] (JndiJdbcWithValidationTableView.java:56) - doGet(1200427675938) - Ok connexion
[2008-01-15 20:07:55,939][DEBUG] (JndiJdbcWithValidationTableView.java:60) - doGet(1200427675938) - Appel Boxers => bdSelectAll
[2008-01-15 20:07:55,941][DEBUG] (net.milamberspace.dao.DaoBoxers.java:24) - bdSelectAll(1200427675938) - SQL => SELECT ID, PRENOM, NOM FROM BOXERS
[2008-01-15 20:07:55,941][INFO ] (DirectJdbcTableView.java:60) - doGet(1200427675929) - Ok connexion
[2008-01-15 20:07:55,942][DEBUG] (DirectJdbcTableView.java:64) - doGet(1200427675929) - Appel Boxers => bdSelectAll
[2008-01-15 20:07:55,942][DEBUG] (DaoBoxers.java:24) - bdSelectAll(1200427675929) - SQL => SELECT ID, PRENOM, NOM FROM BOXERS
[2008-01-15 20:07:55,947][DEBUG] (DaoBoxers.java:27) - bdSelectAll(1200427675938) - ResultSet ok => org.apache.tomcat.dbcp.dbcp.DelegatingResultSet@17dde01
[2008-01-15 20:07:55,948][DEBUG] (DaoBoxers.java:36) - bdSelectAll(1200427675938) - Retour list
[2008-01-15 20:07:55,949][DEBUG] (JndiJdbcWithValidationTableView.java:62) - doGet(1200427675938) - Mise en attribut resultat
[2008-01-15 20:07:55,949][DEBUG] (JndiJdbcWithValidationTableView.java:64) - doGet(1200427675938) - Renvoi vers JSP
[2008-01-15 20:07:55,950][DEBUG] (DaoBoxers.java:27) - bdSelectAll(1200427675929) - ResultSet ok => com.mysql.jdbc.ResultSet@7a3c6c
[2008-01-15 20:07:55,952][DEBUG] (DaoBoxers.java:36) - bdSelectAll(1200427675929) - Retour list
[2008-01-15 20:07:55,952][DEBUG] (DirectJdbcTableView.java:66) - doGet(1200427675929) - Mise en attribut resultat
[2008-01-15 20:07:55,952][DEBUG] (DirectJdbcTableView.java:68) - doGet(1200427675929) - Renvoi vers JSP
[2008-01-15 20:07:55,954][DEBUG] (DirectJdbcTableView.java:85) - doGet(1200427675929) - end
[2008-01-15 20:07:55,956][INFO ] (DirectJdbcInInitTableView.java:57) - doGet(1200427675934) - Ok connexion
[2008-01-15 20:07:55,956][DEBUG] (DirectJdbcInInitTableView.java:61) - doGet(1200427675934) - Appel Boxers => bdSelectAll
[2008-01-15 20:07:55,957][DEBUG] (DaoBoxers.java:24) - bdSelectAll(1200427675934) - SQL => SELECT ID, PRENOM, NOM FROM BOXERS
[2008-01-15 20:07:55,958][DEBUG] (JndiJdbcWithValidationTableView.java:78) - doGet(1200427675938) - end
[2008-01-15 20:07:55,961][DEBUG] (DaoBoxers.java:27) - bdSelectAll(1200427675934) - ResultSet ok => com.mysql.jdbc.ResultSet@283198
[2008-01-15 20:07:55,963][DEBUG] (DaoBoxers.java:36) - bdSelectAll(1200427675934) - Retour list

Cela permet une lecture plus facile des logs (la couleur n’est pas incluse ), dès lors que l’on sait utiliser la commande grep sous Unix en faisant quelques petits grep sur l’identifiant. (par exemple : grep 1200426850018 mon_log.txt)

Comme faire pour utiliser NDC ? Et bien tout d’abord dans le fichier de configuration de Log4J, le fameux log4j.properties. Il faut ajouter la balise « %x » dans le ConversionPattern, celle-ci sera remplacée par l’identifiant unique défini lors de l’utilisation de NDC.

Exemple de fichier log4j.properties

log4j.rootLogger=DEBUG, LOG1
log4j.appender.LOG1=org.apache.log4j.ConsoleAppender
log4j.appender.LOG1.layout=org.apache.log4j.PatternLayout
log4j.appender.LOG1.layout.ConversionPattern=[%d][%-5p] (%C.java:%L) - %M(%x) - %m%n

Au niveau du code source Java, on utilisera deux méthodes de la classe statique NDC.

• NDC.push(String ID) qui permet de poser un identifiant
• NDC.pop() qui permet de dépiler le dernier identifiant posé

Voici un exemple simple d’utilisation pour une servlet, avec ici, l’utilisation de « new Date().getTime() » comme identifiant :

protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
 NDC.push(String.valueOf(new Date().getTime()));
 logger.debug("start");
 Connection connection = null;
 try {
 	connection = getDataSource().getConnection();
 	logger.info("Ok connexion");
	DaoBoxers dao = new DaoBoxers();
 	dao.setConnection(connection);
 	ArrayList list = dao.bdSelectAll();
 	request.setAttribute("beanListeBoxer", list);
 	this.getServletContext().getRequestDispatcher("/tableview.jsp").forward(request, response);
 } catch (Exception e) {
 	logger.error(e);
 	throw new ServletException(e.getMessage());
 } finally {
 	try {
 		connection.close();
 	} catch (SQLException sqle) {
 		logger.error(sqle);
 	}
 	logger.debug("end");
 	NDC.pop();
 }
}

Bien entendu, les appels à logger.xxxx() dans les méthodes du DAO vont également bénéficier de l’identifiant NDC.

Espérons que ce billet vous sera utile.

La page de manuel de Log4J.

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…

Commençons par la génération du heap dump. La bonne nouvelle, c’est que depuis les versions Java 1.4.2 update 12, Java 5 update 07 et Java 6, la génération de heap dump est « devenu » facile. Pour avoir un heap dump automatique dès que vous avez une erreur OOME, il faut simplement ajouter ce paramètre -XX:+HeapDumpOnOutOfMemoryError dans les arguments de la JVM. La mauvaise nouvelle, c’est que pour les versions antérieures, c’est plus difficile d’obtenir un heap dump. Cela dépend de l’éditeur de la JVM que vous utilisez (IBM, BEA, Sun, HP, etc), il faut se reporter sur le site de l’éditeur pour trouvez la bonne recette…

Une fois que l’on a trouvé le bon paramètre pour générer son heap dump, il ne reste plus qu’à le mettre en production et attendre l’erreur fatal d’OOME. Quand celle-ci arrive, on attend la génération du fichier qui peut prendre plusieurs minutes car le fichier aura la taille de la JVM au moment de l’erreur. Donc si la taille maximum est à 1Go, le fichier va faire 1Go.

Maintenant que l’on a son fichier heap dump, il faut l’analyser…et là aussi c’est pas simple. Il existe différents moyens, allant du mode texte (via Hprof) vers des outils tels que Heap Analyzer de IBM ou bien HAT (ou JHAT maintenant) de Sun. Le gros problème de ses outils, c’est que c’est quasiment impossible d’ouvrir un heap dump d’1Go avec. Vous avez un OutOfMemoryError de l’outil

La bonne nouvelle c’est que l’éditeur SAP a pensé à nous, à travers son outil d’analyse Memory Analyzer. Ce dernier est basé sur l’environnement RCP d’Eclipse. Il ouvre sans difficulté un heap dump de 1Go, car il analyse le fichier heap dump petit à petit et en créant ses propres fichiers d’index. (Il faut compter environ 1h30 pour ouvrir un fichier 1,2Go sur un portable Vista avec 2Go de RAM, Core 2 Duo 2GHz)

Memory Analyzer dispose de nombreuses fonctionnalités, dont l’une qui va nous intéresser particulièrement : la détection de fuite de mémoire (find memory leaks). De plus il dispose de tutoriaux pour aider à l’analyse de fichier heap dump.

Voici quelques captures d’écran qui en diront plus que mes longs discours :

Détails d’un heap dump.

Histogramme, détails par classe : nombre d’objets, taille la plus petite de l’objet, taille des objets

Inspector pour avoir le détail et le contenu d’un objet

La détection de fuite de mémoire, ici un objet détient à lui tout seul 657 Mo sur 1024 Mo ! Cela sent le memory leaks…

Analyse de la fuite mémoire, la cause ici semble être une liste HashMap de + de 490000 objets.

[Quelques pointeurs]

• SAP Memory Analyzer
• Heap dumps are back with a vengeance!
• HAT — The Java Heap Analysis Tool
• IBM : HeapRoots : A tool for debugging memory leaks in Java applications through analysis of « heap dumps. »
• IBM : HeapAnalyzer : A graphical tool for discovering possible Java heap leaks.
• IBM : Using HeapAnalyzer to analyze Java heap usage and detect possible Java heap leak
• BEA : Memory Leaks, Be Gone!
• Java diagnostics, IBM style, Part 1: Introducing the IBM Dump Analyzer for Java
• Java diagnostics, IBM style, Part 2: Garbage collection with the Extensible Verbose Toolkit