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

[Adnan Raza (JIRA)]

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

Adnan Raza commented on JBAS-5570:
----------------------------------

I have experience similar problem but in my case it's on a swf file that is our application on the production server. And When we access the URL of our application the exception gets printed which is java.io.FileNotFoundException (Too Many Files Open). The Address shown of the swf points to the location in jboss-as/server/production/tmp/ .. ..   
and this location is not scanned by JBoss Deployer because the deployer only scans files in the deploy directory not temp/deploy right??

But I had restarted the jboss server to fix this problem and that worked for now. 

If anyone has an idea please do comment ASAP, thanks.



> 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