Lecture de properties - Too many open files

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:

---

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.

Bonjour.

Oui !

Code:

---

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

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, ...

salut,

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

Code:

---

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

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

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...

:arrow: En les fermant proprement le problème disparaitra ;)

Citation:

---

Envoyé par yann2

(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:

---

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++

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

Code:

---

1 2 3

finally { in.close(); }

---

Merci à tous :)

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

Code:

---

1 2 3 4 5 6

finally { if(in != null){ in.close(); } }

---

:lol::lol::lol:

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:

---

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++