Summary: | First access to a jspx page causes classloader leak in JspDocumentParser | ||
---|---|---|---|
Product: | Tomcat 6 | Reporter: | Konstantin Kolinko <knst.kolinko> |
Component: | Jasper | Assignee: | Tomcat Developers Mailing List <dev> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | P2 | ||
Version: | 6.0.29 | ||
Target Milestone: | default | ||
Hardware: | PC | ||
OS: | Windows XP |
Description
Konstantin Kolinko
2010-12-11 21:33:47 UTC
Waw, that's a nice bug in the JVM ! To avoid it in tomcat, I vote for 2) Do not cache the Exception. Create a new instance each time. 2 gets my vote I found another place where the same type of leak might occur : in ProxyDirContext (in tc7, I dod not check with tc6), there is protected static final NameNotFoundException NOT_FOUND_EXCEPTION = new ImmutableNameNotFoundException(); In this case the stack does not contain webapp code, so there's no leak of webapp classloader. But there can be a leak of tomcat's classloader if it is embedded... Fixed in trunk in r1044987 and will be in 7.0.6. I will propose it for 6.0 and 5.5. I should note, that 3) fixes the issue in my environment. For the JspDocumentParser$EnableDTDValidationException class I am using 2) as the fix and 3) for sake of performance. For the ImmutableNameNotFoundException class I am using 3), as 2) would be too much of a change for me. (In reply to comment #3) > But there can be a leak of tomcat's classloader if it is embedded... ProxyDirContext is loaded by the Tomcat's classloader as well, and thus it static field should be GC'able at the same time as the Tomcat classes that might appear in the stacktrace there. So I do not think that there will be an observable leak with ProxyDirContext. FWIW, I still vote #2. I'm pretty sure that actually throwing the exception is more costly than creating the Exception object. Fixed in 6.0.x and will be included in 6.0.30 onwards. Fixed in 5.5.x and will be included in 5.5.32 onwards. |