Je suis confronté à l'exception java.io.FileNotFoundException: (Too many open files) et de chercher les moyens de le résoudre. Cette erreur indique évidemment que la JVM a alloué trop de poignées et de l'OS sous-jacent ne le laissera pas en avoir plus. Soit j'ai une fuite quelque part avec mal fermé connexions/flux ou autres joyeusetés.., ou la JVM est stressée - nous parlons d'un processus serveur qui s'exécute pour les jours non-stop et finalement se dessèche. Il se produit à plusieurs reprises après 12 à 14 jours de temps de fonctionnement.
J'ai triple vérifié le code et n'a trouvé aucune fuites apparentes. Il y a cependant des bibliothèques tierces qui sont largement utilisés tels que l'e-mail, le quartz, les planificateurs, hibernate et quelques autres.
Maintenant.. Comment voulez-vous lutter contre cela? Est-il possible d'obtenir une liste de descripteurs dans la JVM ou de la piste lorsqu'il atteint un certain montant? Je serais ravi de les imprimer et de voir comment il se développe, et quand. Je ne peux pas utiliser un profiler parce que c'est un système de production et ont de la difficulté à le reproduire en développement. Toute suggestion?
MODIFIER
OK, j'ai reçu quelques très utiles, merci les gars! Mais encore.. Ce que je suis en train d'essayer de comprendre est de savoir si c'est possible pour la JVM de savoir combien de poignées, il peut ouvrir, combien d'entre eux sont déjà ouverts, et, éventuellement, quels sont-ils. Par exemple, je suis de surveillance gratuit de la taille du segment et en déclenchant une "alarme" quand il approche de 1% du total spécifié-Xmx. Je sais aussi que si mon thread nombre de coups au-dessus de 500, alors quelque chose va certainement sortir de la main. Maintenant, est-il un moyen de savoir que mon JVM alloue trop de poignées à partir de l'OS et ne leur donne pas de retour, par exemple, les sockets, les fichiers ouverts, etc. Si j'avais su cela, je voudrais savoir où chercher et quand.
EDIT-2 J'ai réussi à trouver quelque chose de suspect, peut-être cela pourrait être une raison pour que les ressources des fuites. C'est à propos de log4j Récepteurs de colis. Son support récepteur a une très poilue bug dans la gestion de la accepté de sockets. Il conserve tous accepté de sockets dans un vecteur en lançant un thread séparé pour communiquer vers le point de fin. Lorsqu'un client met fin à la connexion, le thread meurt, mais la prise de l'instance reste dans le récepteur vecteur pour toujours. Que, bien sûr, s'accumulent dans le temps. Mais je ne suis toujours pas sûr si socket fermée encore alloue de l'OS de la poignée...
