Construction d'objets à partir de nombreux documents XML -> HEAP SPACE EXCEPTION

Bonjour à tous,

Je développe un traitement qui récupère du contenu XML provenant d'un web service pour construire des objets. J'ai développé tous mes traitements pour une dizaine de documents XML, sauf qu'en réalité, je dois en traiter une cinquantaine, et là j'ai un soucis de mémoire (java.lang.OutOfMemoryError: Java heap space).

Au fur et à mesure des traitements, le processus de ma JVM monte en mémoire jusqu'a plus d'1Go et ça finis toujours par planter...

J'ai bien vu qu'il existait d'autres moyens pour traiter du XML comme SAX seulement j'ai besoins de parcourir les noeuds de mes documents et de vérifier certaines informations avant d'en extraire le contenu, ce que je trouve plus facile à réaliser avec DOM.

Y a t-il une ou des mauvaises pratiques à éviter avec DOM pour ménager la mémoire ?

J'utilise une classe avec des fonctions static pour traiter le XML, je déclare mes InputSource, Document et NodeList comme variables de classe, les instancie au début de mes fonctions et les met à null après les avoirs utilisés.

Code:

---

1 2 3 4

builder = factory.newDocumentBuilder(); is = new InputSource(new StringReader(xml)); doc = builder.parse(is);

---

Je devrais peut-être faire un vrai singleton ? Et initialiser ces éléments communs à mes fonctions via le getInstance() ?
J'attend vos conseils, je peux présenter du code mais je ne sais pas où commencer :aie:

Salut,

Utilise un profiler pour répérer les instances qui stagnent en mémoire, ça te permettra de répérer les fuites de mémoires. S'il n'y en a pas, c'est que manifestement ton programme à besoin de plus de heap et il te suffira de l'augmenter (paramètre -Xmx).

Par ailleurs, d'où viennent les XML ? Je vois que tu utilises un StringReader, donc xml est une String, mais comment est produite cette String ? Si c'est par une lecture de fichier, libères-tu bien les ressources ayant servi à lire les fichiers ?

Citation:

---

Envoyé par StripMat

J'utilise une classe avec des fonctions static pour traiter le XML, je déclare mes InputSource, Document et NodeList comme variables de classe, les instancie au début de mes fonctions et les met à

---

Pourquoi ne simplement utiliser des variables locales (à la méthode) ?

Les XML proviennent d'un web service, que je récupère en string comme ceci

Code:

---

xmlReponse = EntityUtils.toString(httpResponse.getEntity(), "UTF-8");

---

Je vais voir de ce côté là, c'est peut-être ma classe Http qui n'est pas bien conçue mais j'en doute. Je vais voir pour utiliser un profiler.

Concernant les variables locales, en fait j'avais conçue ma classe comme ça, mais j'ai pensé que ce serait moins lourd en mémoire de n'utiliser qu'un seul objet déclaré en variable de classe et écrasé à chaque nouvel appel de fonction, mais ça n'est visiblement pas le cas :mouarf:

J'ai essayé d'augmenté la taille du HEAP SPACE à -Xmx1024m mais ça n'est toujours pas suffisant. Je réessaye avec 2048. :aie:

Je vais voir aussi si les XML que je cherche à traiter ne sont pas trop volumineux, j'ai lu quelque part qu'il fallait 12x plus de mémoire que la taille du XML à traiter avec DOM. Mais bon, ce qui est étrange c'est que plus j'ai de documents, plus la mémoire monte...

Je test tout ça.

Citation:

---

Envoyé par StripMat

Concernant les variables locales, en fait j'avais conçue ma classe comme ça, mais j'ai pensé que ce serait moins lourd en mémoire de n'utiliser qu'un seul objet déclaré en variable de classe et écrasé à chaque nouvel appel de fonction, mais ça n'est visiblement pas le cas :mouarf:

---

Strictement aucune différence dans l'occupation mémoire, sauf qu'il faut juste penser à les mettre à null, et que ta méthode est stateless, donc non utilisable en multi-thread.

Citation:

---

Envoyé par StripMat

J'ai essayé d'augmenté la taille du HEAP SPACE à -Xmx1024m mais ça n'est toujours pas suffisant. Je réessaye avec 2048. :aie:

---

Oui, ça fait beaucoup. Il faut voir la taille de tes xml (le nombre de nodes). Déjà, si tu peux traiter le plus gros de tes xml, avec une mémoire donnée, mais que tu ne peux pas en traiter plusieurs d'affilée, c'est plutôt côté fuite de mémoire qu'il faut investiger.

Citation:

---

Envoyé par StripMat

Je vais voir aussi si les XML que je cherche à traiter ne sont pas trop volumineux, j'ai lu quelque part qu'il fallait 12x plus de mémoire que la taille du XML à traiter avec DOM.

---

Tout dépend déjà de l'API DOM que tu utilises (JavaSE, JDOM...). Bien sûr, utiliser StAX est toujours intéressant avec des gros documents, pas seulement pour l'empreinte mémoire, mais aussi pour les performances (créer plein d'instances de nodes va beaucoup solliciter le GC pour les libérer).

Citation:

---

Envoyé par StripMat

Mais bon, ce qui est étrange c'est que plus j'ai de documents, plus la mémoire monte...

---

Un signe qui pourrait confirmer la fuite de mémoire (enfin pas forcément, mais combiné avec l'outofmemory, c'est une hypothèse plus que probable).

Merci beaucoup pour ces indications, j'ai pu installer et réaliser une analyse avec un Profiler, il me reste plus qu'a comprendre ce qu'il me dit. J'en sais un peu plus sur quels éléments porter mon attention.

PS: Je sais pas si l'indication est bonne, mais avec un String.getBytes("utf-8").length / 8 certains de mes XML feraient plus de 3Go :aie: mais sa semble passer, en revanche même avec 2Go d'alloués en Heap Space, sa plante encore au bout de X fichiers traités, certains faisant de 3Mo à +3Go :calim2:

To be continued...

Citation:

---

Envoyé par StripMat

PS: Je sais pas si l'indication est bonne, mais avec un String.getBytes("utf-8").length / 8 certains de mes XML feraient plus de 3Go

---

Pourquoi le / 8 ?
Attention, en utf-8, un caractère ne donne pas forcément un octet, mais ça peut aller jusqu'à 4 en normalisé (8 en théorie). La plupart des caractères (alphanumérique, symboles standards, y compris de syntaxe xml, les caractères accentués usuels en français), c'est 1 octet, avec certains symboles courants sur 2, et certains caractères spéciaux usuels sur 3 (symbole de l'euro, espaces typographiques...).
Penser au problème de la fuite de mémoire possible avec String.substring (pour les version anté Java7 update 6 de mémoire).

Mais même si tes strings faisait "seulement" 400Mchar, je pense qu'il faudrait envisager un traitement en stream/StAX.

Attention, il y a une taille max de heap (il me semble, 4Gi en 32bits (2Gi sur Windows), 2⁶⁴ en 64bits).

Citation:

---

Envoyé par joel.drigo

Pourquoi le / 8 ?

---

Parce que j'ai été trop vite, j'ai cru récupérer des bits, dont je divise le nombre pour avoir mes octets, sauf que oui, 1 byte = 1 octet in english :aie:

Je pense changer complètement mes traitements XML et utiliser StAX, j'ai testé hier et le temps d'exécution n'a rien à voir, aujourd'hui il faut environs 10min pour charger et traiter une trentaine de documents XML, peut mieux faire :mouarf:

Mais j'ai un peu de mal encore avec StAX et son fonctionnement, et y a pas masse de doc francophone :?

EDIT: J'ai rien dit, y a de la doc francophone, faut juste que je prenne le temps de comprendre ;)

Pour StAX en français :

1. http://hikage.developpez.com/java/articles/xml/stax/
2. http://jmdoudoux.developpez.com/cour.../chap-stax.php

Le principe est simple, encore plus si tu connais déjà Sax. Le process du stream déclenche des "évenements" : en SAX, ça se caractérise par l'implémentation d'une méthode d'un handler, en mettant le code qu'on veut faire lorsqu'on rencontre cet "évenement", les paramètres de la méthode étant les valeurs circonstancielles (par exemple, pour l'évenement "startElement", début d'élément, on a le nom de l'élément en paramètre. En StAX, c'est pareil, mais pas de méthode dans un handler : juste un état (sur un curseur, ou sur une instance de classe représentant un évenement), et des méthodes pour récupérer les paramètres circonstanciels.
Il y a 2 formes d'API StAX, une plus orienté curseur (l'évenement est un simple état à tester dans un switch et on parcourt les différents évenements un peu comme on parcourt les records dans un ResultSet pour une requête jdbc ), et une plus orientée itérateur (une classe XmlEvent caractérise l'évenement). La plupart du temps, une pile (Deque), pour connaitre le namespace courant, et un StringBuilder, pour construire les contenus texte, suffisent à traiter la plupart des cas. Seuls les cas de références interéléments peuvent poser des problèmes techniques (on peut avoir à stocker des handles de fonctions à exécuter plus tard pour traiter certaines références).
Pour la sérialisation, on ne fait que simuler des évenements, dans un mode descriptif (créer elément, ecrire attribut, écrite contenu, fermer élément...)

Hier j'ai testé SAX, mais j'avais moyennement compris ce que je faisais.

Là j'avoue que j'avale de la doc en masse mais j'ai vraiment du mal à la comprendre, ne serait-ce quelle API employer pour traiter mon XML, curseur ou événement... :(

Je vais essayer de comprendre et d'appliquer, je reviendrais avec un XML et du code si j'galère, merci encore pour avoir pris le temps de me répondre.

EDIT: C'est en forgeant qu'on devient forgeront, j'ai réussi à l'utiliser pour récupérer rapidement deux trois données et niveau temps d'exécution ça n'a rien à voir ! Par contre je prévoie plus de temps pour développer mes traitements, je sens que sa va vite se compliquer :mouarf:

Je suis partit sur un XMLStreamReader, et si j'ai bien compris, les informations ne sont disponible qu'une fois sans retour arrière dans le fichier possible.

C'est donc normal si :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

//ok System.out.println(reader.getElementText()); //nom=reader.getElementText();   //ok //System.out.println(reader.getElementText()); nom=reader.getElementText();   //Current state not START_ELEMENT System.out.println(reader.getElementText()); nom=reader.getElementText();

---

Comment faire si je veux utiliser plusieurs fois la même donnée ? C'est quand même c*n d'avoir à faire ça :mouarf:

Code:

---

1 2 3 4

String value = reader.getElementText(); System.out.println(value); nom=value;

---

Citation:

---

Envoyé par StripMat

Je suis partit sur un XMLStreamReader, et si j'ai bien compris, les informations ne sont disponible qu'une fois sans retour arrière dans le fichier possible.

---

C'est sûr, c'est peu le principe des streams, ce qui est consommé est consommé.

Citation:

---

Envoyé par StripMat

Comment faire si je veux utiliser plusieurs fois la même donnée ? C'est quand même c*n d'avoir à faire ça :mouarf:

Code:

---

1 2 3 4

String value = reader.getElementText(); System.out.println(value); nom=value;

---

---

Ça dépend. De quoi et comment.
Par exemple, si tu as besoin de connaître l'élément dans lequel tu te trouves, tu peux utiliser une pile (une ArrayDeque).

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

final XMLStreamReader r = XMLInputFactory.newInstance().createXMLStreamReader( inputStream );   final Deque<String> stack = new ArrayDeque<>(); while(r.hasNext()) { switch( r.next() ) { case XMLStreamReader.START_ELEMENT: // chaque fois que je commence un élément, j'empile son nom stack.push(r.getLocalName()); break; case XMLStreamReader.END_ELEMENT: stack.pop(); // chaque fois que je termine un élément je dépile break; case XMLStreamReader.CHARACTERS:     System.out.println("L'élement dans lequel se trouve ce contenu s'appelle : " + stack.peek());   // j'affiche le bread crump Iterable<String> it = ()-> stack.descendingIterator(); System.out.println(StreamSupport.stream(it.spliterator(),false).collect(Collectors.joining(" / "))); break; }   }

---

Si tu as besoin d'associer des infos (des valeurs d'attributs) avec des noms d'éléments, tu peux utiliser une Map. Il y a plein de cas, selon les besoins. Il faut voir également si la donnée peut être stockée dans une variable simple (selon sa portée dans l'arbre). On est obligé d'empiler si les éléments ont possiblement un contenu multiple. On peut mixer selon les cas : si on sait que pour élément "toto", il n'y a jamais qu'une seul élément à l'intérieur, on peut stocke un de ses attributs dans une variable String, et tester if ( stack.peek().equals("toto") & attrbval!=null ), utiliser des booléens pour savoir si on est dans une section dont on sait qu'elle est forcément unique (on s'en fout d'avoir une variable avec le nom, on veut juste savoir si on est dedans ou pas).

Au vu de tous les éléments que tu m'as fournis, j'ai tout ce dont il me faut pour bosser.

Merci beaucoup Joel pour toutes ces explications, je m'en sors pas trop mal j'ai déjà presque réécris tous mes traitements DOM en utilisant StAX, le seul soucis que je rencontrais c'était comment faire persister certains informations lors de la lecture du stream mais tu y as répondu avec l'explication concernant l'objet Deque.

Merci encore, tu m'as grandement éclairé. ! :D