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

[Toomas Rￃﾃￂﾶmer (JIRA)]

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.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira