Discussion :

[Romz_Java]

Bonjour,

j'aurais besoin d'aide pour résoudre un problème au chargement des properties d'une appli J2EE. J'ai une classe Configurateur qui étend Properties et qui charge les fichiers de properties à partir de leur url avec cette instruction:

Code :

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

this.load(url.openStream());

La modification des properties est prise à chaud donc je scrute périodiquement les fichiers de config, et au bout d'un moment j'obtiens cette erreur:

java.io.FileNotFoundException: "Nom du fichier" (Too many open files)

Visiblement il y a saturation du descripteur de fichier. Est-il nécessaire de faire quelque chose de particulier pour refermer correctement les fichiers après leur lecture?

Merci d'avance si vous pouvez m'aider.

[yann2]

Bonjour.

Oui !

Code :

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

1
2
3
4
5
6
7
8
9
10
 
InputStream in = null;
try {
   in = url.openStream();
   this.load(in);
} finally {
   if (in != null) {
     in.close();
   }
}

(Sans oublier la gestion des IOException, ce qui dépend de la signature de la méthode).

Yann

[boijea]

Bonjour,

Il y a très longtemps, vraiment très longtemps, avant que le C++ existe, je me souviens d'avoir dû recompiler le Kernel Linux pour augmenter le nombre de file descriptor. C'est soit un problème d'OS ou de ton application (serveur j'imagine, qui a trop de fichiers ou de sockets ouverts, ou tu as laissé des streams non fermés dans des objets qui sont encore en utilisation).

Tu as sans doute plusieurs centaines de file descriptor.
Il faudrait essayer d'obtenir combien sont alloués.

Il faudrait avoir plus de détails: application, OS, EJB, ...

[rberthou]

salut,

Si tu es sous Linux regarde la commande "ulimit -a" cela te donne pas mal d'informations sur ta configuration .

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 49152
max locked memory       (kbytes, -l) 32
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 10240
cpu time               (seconds, -t) unlimited
max user processes              (-u) 49152
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

Cette commande te permet également de modifier ces données

[sewatech]

Il me semble aussi que la variable d'environnement $MAX_FD peut être utile.

[adiGuba]

Salut,



A moins que tu n'ai de très gros besoin qui t'oblige à ouvrir en simultanée un très grand nombre de fichier, tu ne devrais pas à modifier la limite système.

Comme l'indique yann2, ton problème vient du fait que tu ne fermes pas tes flux, et donc tu augmentes petit à petit le nombre de fichier/ressources ouvertes...

En les fermant proprement le problème disparaitra

(Sans oublier la gestion des IOException, ce qui dépend de la signature de la méthode).

Tu n'as pas besoin de gérer les null, et tu peux utiliser la syntaxe suivante :

Code :

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

1
2
3
4
5
6
7
 
InputStream in = url.openStream(); // Si IOException rien n'est exécuté
try {
   this.load(in);
} finally {
   in.close();
}

Plus d'info dans la FAQ : Comment libérer proprement les ressources (ou comment utiliser proprement les bloc try/finally) ?


a++

[Romz_Java]

Effectivement, le problème est résolu avec la clause finally qui ferme le flux

Code :

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

1
2
3
finally {
   in.close();
}

Merci à tous

[baloo2401]

Je veux pas faire mon chieur mais juste pour eviter que une autre exception tu devrais plutot écrire :

Code :

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

1
2
3
4
5
6
 
finally {
   if(in != null){
      in.close();
   }
}

[adiGuba]

Non... Dans le code tel que je l'ai donné la variable in ne peut jamais être null dans le finally.

A la rigueur si tu veux t'en assurer, le plus simple et lisible serait de déclarer la variable final :

Code :

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

1
2
3
4
5
6
final InputStream in = url.openStream(); // Si IOException rien n'est exécuté
try {
   this.load(in);
} finally {
   in.close();
}

a++