Lecture d'une stacktrace en Java 08/01/2015

Cet article présente quelques informations intéressantes pour lire une stacktrace lors du log d'une exception par exemple.

Tout d'abord, un petit rappel sur la lecture d'une trace d'exception : il s'agit du cheminement d'exécution du programme jusqu'à l'erreur survenue. Une trace de pile (stack trace) et donc le dernier élément survenu est toujours le premier récupéré par les logs et on remonte la chronologie en lisant la trace par le bas.

Dans le cas où l'exception est la conséquence d'autres exceptions indiquées par le code en tant que cause, des cause by... permettront de retracer l'origine de l'erreur. Il faut donc dans ce cas, se focaliser sur ce point.

La trace, en plus d'indiquer le type d'exception survenue, complètera par des informations sur la signature de la méthode dans laquelle l'erreur est survenue: Le nom canonique de la classe et le nom de la méthode ainsi que les paramètres d'appel et le paramètre de retour.

On aura donc une trace de la forme : [package].[className].[methodName]([parametersIn])[parameterOut]

Par exemple :

org.springframework.cache.annotation.CacheAnnotationParser.
                  parseCacheAnnotations(Ljava/lang/reflect/AnnotatedElement;)Ljava/util/Collection;

Les arguments ont une notation particulière comme on peut le voir dans l'exemple.

Chaque argument est donc présenté de cette forme : [Type][(optional)[package].[className]];

Où Type sera :

DevFest Nantes 2014 18/11/2014

LogoDevFest Retour sur le DevFest 2014 qui a eu lieu à la cité des congrès de Nantes le 07/11/2014.

Profiler une JVM de Zimbra Mailbox 05/09/2014

Simple envie...

Sur une application actuellement en production, suite à une montée de version de Zimbra CS 7 à Zimbra CS 8, nous avons constaté des temps de traitement Batch plus longs sur un WebServices Zimbra appelé en boucle pour des grosses volumétries. L'envie nous a donc pris de voir, comment le changement de version associé à une grosse volumétrie, impactait autant le temps de traitement du webservice Zimbra. Nous sommes partis sur un profiling de JVM.

Comment ?

  • Utilisation de JProfiler6 (certes pas tout récent mais nous avions une licence dispo sous la main pour cette version)

    Pour utiliser JProfiler (comme d'autres outil de profilage), il faut mettre un agent au niveau de la JVM. Les explications complètes sont ici mais en résumé, il faut récupérer les librairies de l'agent en fonction de l'environnement et ajouter l'option suivante à la commande Java :

    
    *Les librairies sont contenues dans le répertoire bin d'une installation de JProfiler donc si vous souhaitez profiler un JVM s'exécutant sous Linux, depuis une GUI JProfiler sous Windows, alors il vous faudra une installation de JProfiler pour Linux (x86 ou x64) en plus de l'installation Windows.*
    
  • Configuration de la JVM Mailbox

    Il existe une option mailboxdjavaoptions qui permet de passer des commandes supplémentaires au daemon Mailbox.

    • Modifier les options de JVM : zmlocalconfig -e mailboxd_java_options="...."
    • Récupérer la valeur courante : zmlocalconfig -s mailboxd_java_options
    • Pour ajouter l'option de profilage : zmlocalconfig -e mailboxd_java_options="`zmlocalconfig -s mailboxd_java_options` -agentpath:/path_to_jprofiler_agent_lib"