Discussion :

[Traroth2]

Bonjour,

Depuis peu, j'ai mis en place un système de génération de XML sur un serveur qui est soumis à une forte charge (des dizaines de milliers de XML générés par jour). Les XML générés font de l'ordre de la centaine de Ko. Est-il possible que le problème vienne de JDOM ? Quelqu'un a-t-il déjà eu un problème similaire ? Est-ce que je peux régler ce problème en utilisant par exemple le DOM inclus dans la bibliothèque standard ?

En fait, en y réflechissant, c'est clairement la source du problème. Les XML étant très volumineux et très nombreux, les serveurs génèrent une pléthore d'objets (Element, Attribut, String...) qui encombrent le heap space, ce qui finit par faire tomber le serveur.

Par contre, je ne vois pas quelle solution apporter, à part générer le XML par un moyen unsafe, genre écrire les balises. Quelqu'un connait une alternative ?

[thelvin]

... Il faudrait aussi nous dire quel problème tu as.

Sinon, pour information, 80 000 par jour par exemple, ça fait moins d'un par seconde. Je n'appelle pas ça une forte charge. J'appelle ça "quelque chose qu'il fait tout le temps et qui n'est pas du tout exceptionnel."

Par contre, je ne vois pas quelle solution apporter, à part générer le XML par un moyen unsafe, genre écrire les balises. Quelqu'un connait une alternative ?

Une approche SAX est également consommatrice de ressource et mémoire. Mais beaucoup moins que DOM.

[Morbo]

S'il y a une fuite de mémoire, je pense pas qu'elle vienne de JDom.
Tu dois garder une référence à des objets qui empeche le Garbage Collector de libérer la mémoire.
Un HeapDump te permettrait de voir le nombre d'instances par objets, après faut faire le tri .
Pour en avoir un automatiquement en cas de crash ajoute l'option java :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

-XX:+HeapDumpOnOutOfMemoryError

Il y a un bon article pour analyser la mémoire java :
http://blog.xebia.fr/2008/11/27/anal...oire-dune-jvm/

[Traroth2]

Si, je pense que c'est bien là le problème.
D'après la doc Caucho (on fonctionne sur un serveur Resin), un fail over du serveur se produit quand le garbage collector réussit à récupérer moins de 2% de la mémoire en un seul passage alors que celle-ci est saturée à 98%. Ça aurait tendance à se produire quand on instancie un grand nombre d'objets. Vu la volumétrie, c'est à dire des dizaines de milliers de XML par jour, contenant chacun des milliers de nodes, ça fait un sacré paquet d'objets Java, justement.

Je vais réimplémenter mon système en utilisant StAX, qui a justement été créé pour résoudre ce type de problème.

[Morbo]

Une fois le arbre Jdom serializé de la mémoire vers le disque, tu n'as plus de raison de conserver des références à ce dernier.
Il faut bien vérifier ce point qui n'est pas propre à JDom, mais à l'utilisation de JDom par ton appli.

Le garbage collector va libérer régulièrement la mémoire en scannant les ressources qui n'ont plus de références. Le garbage collector est très efficaces pour recycler des milliers d'objets lorsqu'ils ont une "vie" courte en mémoire.

Des xml de ~100ko, c'est idéal pour une approche Dom, Sax est a utilisé plutôt quand on cherche un traitement évènementiel sur des XML bien plus gros.

[Traroth2]

Attention, je parle bien de StAX (Streaming API for XML), pour générer du XML et non SAX pour le parser. Je me sens bête de ne pas y avoir pensé tout de suite, en fait.

Je pense que le souci, c'est que là, on en est à des millions d'objets instanciés, en fait.
100 ko par fichier xml, chez nous, c'est une petite moyenne. Mais on a bien plus lourd, et sur des dizaines de milliers de connexions par jour.

Le constat, c'est que quand on utilise l'application sur le serveur de test, tout se passe bien, même sur la durée. Ce n'est donc pas à proprement parler une fuite mémoire.
Par contre, quand on passe en production (notre site a pas mal de trafic), ça pète en quelques minutes.