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

[Dan Hinojosa (JIRA)]

    [ http://jira.jboss.com/jira/browse/JBAS-5570?page=comments#action_12418609 ] 
            
Dan Hinojosa commented on JBAS-5570:
------------------------------------

Any idea if there is a patch or if there will be a release shortly?

> 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: Dimitris Andreadis
>
> 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