Download [#JAVASERVERFACES-2734] Serious file handle leak

[JAVASERVERFACES-2734] Serious file handle leak when loading JSF
resources from JARs Created: 07/Feb/13 Updated: 11/Feb/13 Resolved: 11/Feb/13
Status:
Project:
Component/s:
Affects
Version/s:
Fix Version/s:
Closed
javaserverfaces
resources
2.1.18
Type:
Reporter:
Resolution:
Labels:
Remaining
Estimate:
Time Spent:
Original
Estimate:
Environment:
Bug
sparks202
Fixed
None
2 hours
Issue Links:
Related
is related JAVASERVERFACESto
2725
2.1.19, 2.2.0-m10
Priority:
Assignee:
Votes:
Major
Manfred Riem
0
Not Specified
2 hours
Debian Wheezy, amd64 Linux
FileInputStream not closed,
checking ...
Closed
Description
Whilst load testing our monitoring application written using Tomcat 7/JSF 2.1, we noticed
that the Tomcat instance was using many thousands of file handles with only a handle of
users.
For modularity, we bundle our complete set of JSF resources (including some composite
components) into a single resource JAR and then refer to that JAR from multiple web
applications. Generating a list of open file handles using "lsof" showed that we had many
thousands of file handles pointing to our common resource JAR.
Using a debugger, I was able to step through the JSF source code and determined that the
problem is caused by the underlying JDK bug mentioned here:
http://sourceforge.net/tracker/index.php?func=detail&aid=1824122&group_id=794&atid=100794.
In summary, the bug is that if you are accessing a resource from a JAR using JarURLConnection
and call the getLastModified() method, the JDK does not destroy the underlying file handle.
The URLConnection object will eventually be garbage collected within several 10s of seconds,
however under even a moderate load it is possible to have several hundred open handles per
user browsing the site.
During my investigations, I found that there were 2 locations that were causing file
descriptors to leak:
1) ResourceImpl::getResourceHeaders()
2) DefaultFaceletCache::_getLastModified()
Using a similar method to the bug report given above, I created a patch with a workaround for
calling getLastModified() on the JarURLConnection and with further testing on our application
here no longer leaks file handles when being placed under load. The patch is likely to require
some work to get it in a suitable form for the JSF codebase, however since it works I shall
attach it to the bug report for reference.
Many thanks,
Mark.
Comments
Comment by sparks202 [ 07/Feb/13 ]
My proof-of-concept patch against MOJARRA_2_1X_ROLLING can be found here:
http://www.ilande.co.uk/tmp/jsf-2.1-head-jarfilehandleleak.patch
Comment by Manfred Riem [ 11/Feb/13 ]
Applied to 2.1 branch,
svn commit -m "Fixes http://java.net/jira/browse/JAVASERVERFACES-2734, r=rogerk, make
sure we work around lastModified issue plaguing JarUrlConnection."
Sending jsf-ri\src\main\java\com\sun\faces\application\resource\ResourceImpl.java
Sending jsf-ri\src\main\java\com\sun\faces\facelets\impl\DefaultFaceletCache.java
Sending jsf-ri\src\main\java\com\sun\faces\util\Util.java
Transmitting file data ...
Committed revision 11599.
Comment by Manfred Riem [ 11/Feb/13 ]
Applied to 2.2 trunk,
svn commit -m "Fixes http://java.net/jira/browse/JAVASERVERFACES-2734, r=rogerk, make
sure we work around lastModified issue plaguing JarUrlConnection."
Sending jsf-ri\src\main\java\com\sun\faces\application\resource\ResourceImpl.java
Sending jsf-ri\src\main\java\com\sun\faces\facelets\impl\DefaultFaceletCache.java
Sending jsf-ri\src\main\java\com\sun\faces\util\Util.java
Transmitting file data ...
Committed revision 11600.
Comment by Manfred Riem [ 11/Feb/13 ]
Mark,
Thank you for the patch and describing the locations affected!
Generated at Fri May 12 08:26:57 UTC 2017 using JIRA 6.2.3#6260sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.