[jboss-jira] [JBoss JIRA] Commented: (JBAS-5570) URLDeploymentScanner: relies on FileInputStream finalizer - causes too many open files too easily

URLDeploymentScanner: relies on FileInputStream finalizer - causes too many open files too easily ------------------------------------------------------------------------------------------------- Key: JBAS-5570 URL: http://jira.jboss.com/jira/browse/JBAS-5570 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public(Everyone can see) Components: Deployers Affects Versions: JBossAS-4.2.2.GA Environment: Running on Debian unstable with JDK 1.6_06 Reporter: Toomas Römer Assigned To: Ales Justin 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. The problem: Users are getting "Too many open files" exceptions when starting and then using JBoss. The reason: *) 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. Possible solution: Check for the file modification date with explicit closing.