java.io.FileNotFoundException: (Too many open files)
<p>I am confronted by this exception and looking for the ways to solve it. This error obviously indicates that JVM has allocated too many handles and underlying OS won't let it have more. Either I've got leak somewhere with improperly closed connections/streams or whatnot.., or the JVM is getting stressed out - we are talking about a server process which runs for days non-stop and eventually dries out. It repeatedly happens after 12-14 days of up-time. </p>

<p>I've triple checked the code and found no obvious leaks. There are however third party libraries which are extensively used such as e-mail, quartz schedulers, hibernate and some others. </p>

<p>Now.. How do you fight this? Is there a way to get a list of allocated handles in JVM or track when it hits certain amount? I'd love to have them printed and see how it grows and when. I can't use a profiler because it's a production system and have difficulties to reproduce it in development. Any suggestion?</p>

<p><strong>EDIT</strong></p>

<p>OK, I've received some very useful feedback, thanks guys! But still.. What I am trying to figure out is whether it's possible for the JVM to know how many handles it can open, how many of them are already opened, and possibly what are they. For example, I am monitoring free heap size and raising an "alarm" when it approaches 1% of the total specified in -Xmx. I also know that if my thread count hits above 500, then something definitely goes out of hand. Now, <strong>is there a way to know that</strong> my JVM allocates <strong>too many handles</strong> from OS and doesn't give them back, e.g. sockets, opened files, etc. If I'd knew that, I'd know where to look and when.</p>

<p><strong>EDIT-2</strong>
I have managed to find something suspicious, perhaps this might be a reason for the resource leaks. It's about log4j Receivers package. Its socket receiver has a really hairy bug in managing accepted sockets. It keeps all accepted sockets in a vector while spinning a separate thread to communicate to the end point. When a client drops the connection, that thread dies, but the socket instance stays in the receiver's vector forever. That of course piles up in time. But I'm still not sure if closed socket still allocates OS's handle... </p>
