 <p>The entry is completely optional, but the bug you are pointing to is related to compilation, not runtime, so it is highly unlikely that this is the problem.</p> <p>Application Servers are often very file hungry, and if nothing has been done to increase the limit of open files, the default may not be high enough.</p> <p>On CentOS for example, we found that even in QA (not load testing, just functional testing) a server could max out its ulimit with JBoss 4.2.</p> <p>EDIT: The only thing wrong with the code that you posted in terms of holding files open is that you should use <a href="http://stackoverflow.com/questions/2649322/how-do-i-close-a-file-after-catching-an-ioexception-in-java">finally</a> to close your stream. In a server application, it could be that this code often throws an exception, causing files to not be closed (because you don't close them in a finally) and over time those open file handles add up. There are other issues in how you are doing it (like relying on the <code>available()</code> to determine the size of the byte array), but that should not affect your problem.</p> <p>Another possibility is that under *nix systems sockets consume the same resource as files, so it could be that you have too many sockets (above what the system is configured to allow) open, causing this code to be unable to execute.</p>