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

[Joshua Davis (JIRA)]

    [ https://jira.jboss.org/jira/browse/JBAS-5570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12427846#action_12427846 ] 

Joshua Davis commented on JBAS-5570:
------------------------------------

I think I've been running into this issue recently.   I am going to try turning off the deployment scanner:

http://wiki.jboss.org/wiki/TurnDeploymentScannerDown



> URLDeploymentScanner: relies on FileInputStream finalizer - causes too many open files too easily
> -------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-5570
>                 URL: https://jira.jboss.org/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
>            Assignee: 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: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira