I'm a JavaRebel developer from ZeroTurnaround and have been debugging an issue with "Too many open files" with JBoss that we got reported against JavaRebel.
Users are getting "Too many open files" exceptions when starting and then using JBoss.
*) JBoss by default has configured a mbean org.jboss.deployment.scanner.URLDeploymentScanner which scans every 5 seconds for changes in the deployment descriptors
*) The implementation does a connection = URL.openConnection() and then connection.getLastModified() to check for changes.
*) The underlying implementation for regular files is java.io.FileInputStream
*) The resource is not explicitly closed as FileInputStream will doit it by itself in the finalizer()
*) Handles are freed when GC happens (finalizer logic)
I came to this conclusion by getting the number of filehandles (lsof -p <jboss-pid>). Stepping through URLDeploymentScanner and seeing the handles grow by one after every connection.getLastModified(). In all tests the handles grow by one after this call.
I also let the handles grow to a few thousand and then attached a debugger and after hitting a breakpoint called System.gc() on the JVM and the number of filehandles nicely went down to ~380 with my deployment folder.
Check for the file modification date with explicit closing.