Introduction

L’activité d’une plateforme SOA pilotée par un serveur d’applications tel que Weblogic sollicite naturellement une quantité non négligeable de la mémoire du (ou des, en environnement clusterisé) serveur(s) qu’elle gère.
Cette mémoire croit naturellement avec le nombre (généralement croissant) de composants (métier) qui sont déployés, et de leur activité respective.
Ces composants métier peuvent avoir été implémentés avant que la plateforme SOA ne soit de plus en plus sollicitée (car ceci est la raison d’être d’une architecture SOA : nous capitalisons sur son existence en lui faisant prendre en charge toujours plus de services et de flux de données).
De ce fait, les éventuelles imperfections d’implémentation peuvent n’être détectées qu’une fois le volume d’activité arrivé à maturité.
Une fuite mémoire pratiquement imperceptible à l’origine du projet peut devenir critique voire catastrophique une fois que le système d’informations tourne à plein régime.
Nous allons voir comment détecter/anticiper ce genre de problème.

VisualVM

VisualVM est un outil de supervision d’applications Java en cours d’exécution dans une machine virtuelle Java (JVM).
Vous trouverez l’exécutable de VisualVM au sein de votre JDK ici : <JAVA_HOME>/bin/jvisualvm.exe.
Une fois connecté à votre environnement Weblogic, sélectionnez le profil « Memory » comme ci-dessous :

Vous y trouverez tous les objets actuellement instanciés.
Ensuite vous pouvez créer une capture (snapshot) dans le but d’effectuer une analyse à posteriori :

Ouvrez la capture, cliquez droit sur une classe, et sélectionnez « Show Allocations Stack Traces » :

Vous pourrez alors voir apparaître l’arborescence de la pile d’appels de tous les objets instanciés, ce qui vous permettra remonter vers la source du problème, grâce au détail des méthodes successivement invoquées, ainsi que leurs statistiques associées :