Parsing XML file

Version imprimable

Parsing XML file

Ci-dessous mon code:

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
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
import java.io.BufferedWriter;
import java.io.FileWriter;
import java.io.IOException;
 
import org.xml.sax.Attributes;
import org.xml.sax.SAXException;
import org.xml.sax.XMLReader;
import org.xml.sax.helpers.DefaultHandler;
import org.xml.sax.helpers.XMLReaderFactory;
 
 
public class SAXFilterInFile {
  public static void main(String[] args) throws Exception {
 
    if (args.length != 1) {
      System.err.println("Usage: java SAXFilter XML_FileName.xml");
      System.exit(-1);
    }
 
    new SAXFilterInFile(args);
    System.gc();
  }
 
  public SAXFilterInFile(String[] args) throws SAXException, IOException {
    XMLReader parser = XMLReaderFactory.createXMLReader();
    // should load properties rather than hardcoding class name
    parser.setContentHandler(new PeopleHandler());
    parser.parse(args[0]);
  }
 
 
  class PeopleHandler extends DefaultHandler {
    boolean conceptui = false;
 
    boolean conceptname = false;
 
    public void startElement(String nsURI, String localName,
        String rawName, Attributes attributes) throws SAXException {
      // Consult rawName since we aren't using xmlns prefixes here.
      if (rawName.equalsIgnoreCase("conceptui"))
        conceptui = true;
      if (rawName.equalsIgnoreCase("conceptname"))
        conceptname = true;
    }
 
    public void characters(char[] ch, int start, int length) {
     try {
 
      BufferedWriter out = new BufferedWriter(new FileWriter("Testing1.txt",true));   
 
      if (conceptui) {
        out.write("ConceptUI: " + new String(ch, start, length) + " , ");
        System.gc();
        conceptui = false;
      } else if (conceptname) {
        out.write("ConceptName: " + new String(ch, start, length));
        out.newLine();
        System.gc();
        conceptname = false;
      }
       out.close();
     }
 
     catch (IOException e) {
 
            System.out.println("IOException:");
            e.printStackTrace();
 
            }
    }
  }
}

J'ai augmenté la memoire du JVM pour 512MO mais encore j'ai une erreur:
OutOfMemory: Java Heap space

J'ai forcé le Garbage Collector aussi la meme erreur, est-ce je lance bien le garbage collector dans mon code? Si non ou il faut le placer?

Je parse un fichier xml de 450MO sur une machine ayant 1GO de memoire.

Merci d'avance pour votre aide c'est assez urgent:cry:

20/09/2007, 14h06
bulbo

D'apres ce que j'ai vu, il n'y a rien dans ton code qui bouffe vraiment de la memoire, a part SAX bien sur.

Evite les appels explicites au GC, il se debrouille suffisamment bien tout seul.

J'ai l'impression que SAX garde l'ensemble du fichier en memoire, ce qui est etonnant car pas vraiment necessaire dans une approche evenementielle comme SAX.

J'ai jete un oeil dans la doc de SAX mais ils ont l'air de dire que meme de grands documents peuvent etre parses sans probleme.

Tu nous a montre tout ton code, c'est sur ?

Bulbo ;)
20/09/2007, 14h39
Kh4iN3

Salut,

Non je confirme que SAX ne conserve pas en mémoire, c'est d'ailleurs ce qu'il fait qu'il se différencie de DOM.
Si tu accorde 512m de mémoire, meme si tu utilise DOM, si le fichier en fait 420m tu n'aura pas de dépassement (512 - 420 > 0 :D).
Il doit surement y avoir un probleme ailleurs, si tu as encore du code montre nous le.
Mais c'est vraiment étrange... :roll:

EDIT: juste pour essayer, accorde 600m a la vm, le fichier fait 420m, la vm aura encore largement de mémoire pour elle, si tu as encore cette erreur c'est qu'il y a un probleme ailleurs.

a+
20/09/2007, 14h51
bulbo

Citation:

Envoyé par Kh4iN3

Salut,

Non je confirme que SAX ne conserve pas en mémoire, c'est d'ailleurs ce qu'il fait qu'il se différencie de DOM.
Si tu accorde 512m de mémoire, meme si tu utilise DOM, si le fichier en fait 420m tu n'aura pas de dépassement (512 - 420 > 0 :D).
Il doit surement y avoir un probleme ailleurs, si tu as encore du code montre nous le.
Mais c'est vraiment étrange... :roll:

EDIT: juste pour essayer, accorde 600m a la vm, le fichier fait 420m, la vm aura encore largement de mémoire pour elle, si tu as encore cette erreur c'est qu'il y a un probleme ailleurs.

a+

Je suis pas tout a fait d'accord avec toi pour le coup de DOM et des 420, DOM garde l'ensemble des donnees parsees en memoire donc 420Mo minimum. A ca il faut rajouter la structure objet qui 'decore' toutes ces donnees: les Nodes et la a mon avis on est large au dessus des 420 et 512 me parait meme carrement etroit.

Mais SAX ne devrait pas bouffer la memoire comme ca et comme dans le code qu'on a vu les elements sont ecrit dans un fichier et basta .. ya pas de raison non plus pour ce code de planter.

Question subsidiaire: quelle est la taille en gros du texte que tu essayes d'ecrire dans characters(...) ?

Par contre je tiens a te signaler un probleme potentiel: characters ne te retourne pas forcement tout le texte a l'interieur d'un element en une fois. Je sais bien que tu ecris en append dans ton fichier mais tu fais un reset de tes conditionnelles aussi.
Le reset devrait etre fait dans le endElement pour que ce soit correct.

Bulbo ;)
20/09/2007, 15h14
adiGuba
Salut,

Citation:

Envoyé par bulbo

Evite les appels explicites au GC, il se debrouille suffisamment bien tout seul.

+1
Et les appels explicites aux GC peuvent te plomber les perfs...

Citation:

Envoyé par bulbo

A ca il faut rajouter la structure objet qui 'decore' toutes ces donnees: les Nodes et la a mon avis on est large au dessus des 420 et 512 me parait meme carrement etroit.

Sans oublier que les char sont codé sur 2 octets en Java...

Citation:

Envoyé par bulbo

Mais SAX ne devrait pas bouffer la memoire comme ca et comme dans le code qu'on a vu les elements sont ecrit dans un fichier et basta .. ya pas de raison non plus pour ce code de planter.

+1
Je viens de tester ce code avec un fichier de plus de 600 Mo qui ressemble à ceci :
Code:

1 2 3 4 5 <xml> <conceptui>01</conceptui><conceptname>01</conceptname> <conceptui>01</conceptui><conceptname>01</conceptname> <conceptui>01</conceptui><conceptname>01</conceptname> ...
Et j'ai utilisé JConsole pour le surveiller et je ne dépasse pas les 2Mo d'utilisation... (note : j'ai viré tous les System.gc() car sinon le programme moulinait tellement que j'arrivais même pas à m'y connecter avec JConsole).

Sinon perso ce qui me gène c'est que tu réouvres à chaque fois le même fichier à chaque appel de la méthode characters() :?

Ce serait surement mieux d'utiliser openDocument() pour ouvrir le fichier et de le fermer dans endDocument() (et d'utiliser finalize() comme garde-fou).

Sinon tu peux faire une toute petite optimisation sur les write pour éviter la création d'une chaine temporaire en évitant d'utiliser l'opérateur + :

Code:

out.write("ConceptUI: " + new String(ch, start, length) + " , ");

deviendrait :
Code:

1 2 3 out.write("ConceptUI: "); out.write(new String(ch, start, length)); out.write(" , ");
a++
20/09/2007, 15h22
bulbo

adiGuba > Pour le coup des write je ne suis pas sur. A mon avis une concatenation logicielle est meilleure en performance que plusieurs ecritures sur le disque. Quoique dans le code que tu montres y a t'il une ecriture de faite pour chaque write ou est-ce que ca attends un \n ou un appel a flush pour faire l'ecriture ?

Bulbo ;)
20/09/2007, 15h32
adiGuba

Il utilise un BufferedWriter qui sert justement à limité le nombre d'écriture physique sur le disque. Par défaut les BufferedWriter utilise un tableau de 8192 chars dans lequel sont stocké les données à chaque appel de write(), et les données ne sont réellement écrites que lorsque le buffer est plein (ou que l'on force un flush()). Donc on peut faire plusieurs write() mais il n'y en aura que très peu réellement ;)

Quand à la concaténation d'objet je rappelle que cela crée deux objets temporaires puisque ceci :

Code:

out.write("ConceptUI: " + new String(ch, start, length) + " , ");

est équivalent à ceci :

Code:

out.write( new StringBuilder().append("ConceptUI: ").append(new String(ch, start, length)).append(" , ").toString() );

( * : StringBuilder ou StringBuffer selon la version de Java)

Mais bon je ne pense pas que le problème vienne de là...

a++
20/09/2007, 15h59
bulbo

Citation:

Envoyé par adiGuba

Il utilise un BufferedWriter qui sert justement à limité le nombre d'écriture physique sur le disque. Par défaut les BufferedWriter utilise un tableau de 8192 chars dans lequel sont stocké les données à chaque appel de write(), et les données ne sont réellement écrites que lorsque le buffer est plein (ou que l'on force un flush()). Donc on peut faire plusieurs write() mais il n'y en aura que très peu réellement ;)

Quand à la concaténation d'objet je rappelle que cela crée deux objets temporaires puisque ceci :

Code:

out.write("ConceptUI: " + new String(ch, start, length) + " , ");

est équivalent à ceci :

Code:

out.write( new StringBuilder().append("ConceptUI: ").append(new String(ch, start, length)).append(" , ").toString() );

( * : StringBuilder ou StringBuffer selon la version de Java)

Mais bon je ne pense pas que le problème vienne de là...

a++

Moi non plus j'aime juste chipoter :P et mea culpa pour le bufferedwriter j'avions pas fait gaffe.

Bulbo ;)
21/09/2007, 11h01
zouzino

Probleme non resolu

Ben, tout d'abord merci pour votres remarques. J'ai tjs la meme erreur, j'ai essayé ave system.out.println() au lieu de mettre les donnees dans un fichier mais tjs OutOfMemory, il m'affiche les memes donnees que BufferedWriter avant de se bloquer.

Cette erreur me rend fou :aie: Je n'arrive pas a comprendre c'est quoi qui utilise autant de mémoire dans mon code.

PS: C'est tout le code.
21/09/2007, 11h24
adiGuba

Citation:

Envoyé par zouzino

Cette erreur me rend fou :aie: Je n'arrive pas a comprendre c'est quoi qui utilise autant de mémoire dans mon code.

A quoi ressemble le XML lorsque cela plante ?
As-tu un stacktrace qui indique l'origine du OutOfMemory ???

a++
21/09/2007, 11h28
bulbo

Ca pourrait etre du a une chaine trop longue, mais dans ce cas je pense que ce serait une autre exception que out of memory, bizarre quand meme ton probleme.

Tu travailles avec quel version du JDK ?
Tu utilises l'implementation de SAX du JDK ou une autre que tu as mis dans le CLASSPATH ?

Bulbo ;)

Bonjour,

Citation:

Envoyé par adiGuba

Mais bon je ne pense pas que le problème vienne de là...
a++

Je ne suis pas si sûr, tu as tout très bien expliqué donc je n'y reviens pas, mais ça ne coute pas cher de faire ceci :
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 25 26 27 28 29 30 31 32 33 BufferedWriter out; public void characters(char[] ch, int start, int length) { try { if(out == null){ out = new BufferedWriter(new FileWriter("Testing1.txt",true)); } if (conceptui) { out.write("ConceptUI: "); out.write((ch, start, length)); out.write(" , "); // ne pas le faire System.gc(); conceptui = false; } else if (conceptname) { out.write("ConceptName: "); out.write(ch, start, length); out.newLine(); // System.gc(); conceptname = false; } out.flush(); //ne pas oublier out.close() dans le main()!; } catch (IOException e) { System.out.println("IOException:"); e.printStackTrace(); } }
1. on evite la création de la String qui contient les cars
2. on evite la concaténation de String qui implique la création d'un flopée d'obet comme adiGuba l'a si bien expliqué
3. on crée encore 2 objets le fichier et le bufferedWriter alors qu'on écris toujours dans le même fichier => le passer en variable d'instance.

Comme ça on n'as plus de création d'objet dans la "boucle".

PS: edition et ne pas oublier de faire le close du fichier dans le main avec une méthode publique appropriée, ou avec un getter sur le out.

21/09/2007, 15h58
zouzino

Encore et encore Non resolu

J'utilise le jdk1.6.0 et oui j'utilise l'implementation du SAX du jdk.

Une question assez idiote puisque cette erreur me fait tourner la tete:
comment creer la methode publique pour le close du file out d'après deltree:oops:

il n'y a pas de mal ;)
Mais il vaut peut-être mieux le faire dans le handler finalement, c'est plus propre:

Code:

1
2
3
4
5
6
 
void endDocument()
                 throws SAXException{
  out.flush();
  out.close();
}

sinon le truc c'était de garder la main sur l'objet, mais ça fait moins propre:
(donc pour info, mais ne pas le faire si tu modifie le handler)

Code:

1
2
3
4
5
6
7
8
9
10
11
12
 
public SAXFilterInFile(String[] args) throws SAXException, IOException {
    XMLReader parser = XMLReaderFactory.createXMLReader();
    // should load properties rather than hardcoding class name
    PeopleHandler handler = new PeopleHandler();
    parser.setContentHandler(handler);
    handler.getOut().close();
    parser.parse(args[0]);
  }
 
//...dans la classe  class PeopleHandler extends DefaultHandler {
 public Writer getOut(){ return out;}

Toujours la meme erreur

Merci Deltree pour votre aide mais j'ai toujours la meme erreur c'est bizzare.

Essayez s'il vous plait de l'executer chez vous avec un grand fichier xml:

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
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
import java.io.BufferedWriter;
import java.io.FileWriter;
import java.io.IOException;
 
import org.xml.sax.Attributes;
import org.xml.sax.SAXException;
import org.xml.sax.XMLReader;
import org.xml.sax.helpers.DefaultHandler;
import org.xml.sax.helpers.XMLReaderFactory;
 
 
public class SAXFilterInFile {
  public static void main(String[] args) throws Exception {
 
    if (args.length != 1) {
      System.err.println("Usage: java SAXFilter XML_FileName.xml");
      System.exit(-1);
    }
 
    new SAXFilterInFile(args);
 
 
  }
 
 
  public SAXFilterInFile(String[] args) throws SAXException, IOException {
    XMLReader parser = XMLReaderFactory.createXMLReader();
    PeopleHandler handler = new PeopleHandler();
    parser.setContentHandler(handler);
    parser.parse(args[0]);
    handler.getOut().close();
  }
 
 
 
  class PeopleHandler extends DefaultHandler {
 
    boolean conceptui = false;
 
    boolean conceptname = false;
 
    public BufferedWriter getOut() { 
     return out;
    }  
 
    public void startElement(String nsURI, String localName,
        String rawName, Attributes attributes) throws SAXException {
      // Consult rawName since we aren't using xmlns prefixes here.
      if (rawName.equalsIgnoreCase("conceptui"))
        conceptui = true;
      if (rawName.equalsIgnoreCase("conceptname"))
        conceptname = true;
    }
 
    BufferedWriter out;
 
    public void characters(char[] ch, int start, int length) {
     try {
 
      if (out == null){
 
        out = new BufferedWriter(new FileWriter("Testing1.txt",true));   
      }   
 
      if (conceptui) {
        out.write("ConceptUI: ");
        out.write(new String(ch, start, length));
        out.write(" , ");
        conceptui = false;
      } else if (conceptname) {
        out.write("ConceptName: ");
        out.write(new String(ch, start, length));
        out.newLine();
        conceptname = false;
      }
       out.flush();
     }
 
     catch (IOException e) {
 
            System.out.println("IOException:");
            e.printStackTrace();
 
     }
   }
 
  }
 
}

Quand je compile et je lance le programme il me donne l'erreur suivante:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
	at com.sun.org.apache.xerces.internal.util.XMLStringBuffer.append(Unknown Source)
	at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.refresh(Unknown Source)
	at com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.invokeListeners(Unknown Source)
	at com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.arrangeCapacity(Unknown Source)
	at com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.skipString(Unknown Source)
	at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(Unknown Source)
	at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(Unknown Source)
	at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(Unknown Source)
	at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(Unknown Source)
	at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
	at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
	at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
	at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(Unknown Source)
	at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(Unknown Source)
	at SAXFilterInFile.<init>(SAXFilterInFile.java:30)
	at SAXFilterInFile.main(SAXFilterInFile.java:20)

Quand le programme plante il me génère un fichier txt( de taille 1.04MB sur une machine de 1GB de memoire et de taille 2.06 sur une machine de 2 GB) avec une partie des donnees.

Je n'arrive pas à comprendre qu'est ce qui bouffe la mémoire.
Si ca marche pas, proposez vous d'autres solutions pour parser un tel fichier xml en utilisant java bien sur. :(

21/09/2007, 22h47
deltree

Bug jdk1.6

Bien vu de la part d'adiGuba et Bulbo: je me suis complètement fourvoyé, ça ne vient pas de on code, et ça vient de ta version jdk, c'est un bug connu:

http://bugs.sun.com/bugdatabase/view...bug_id=6536111

Donc essaye d'utiliser le jdk1.5 si tu peut, sinon, utilise une librairie.
(ils ne donne même pas le wrokaround sur le site de sun? 8O)
22/09/2007, 18h06
zouzino

Nickel

Finallement, probleme resolu c'etait la version du jdk.

J'ai compile et lance mon programme avec jdk1.5.06 et il marche nickel.

Merci beaucoup Deltree pour votre aide. Quand meme c bizzare ce bug dans jdk1.6 et il fallait trouver une solution pour le resoudre.

A plus tard j'ai plein de travail a faire :D