DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=41324>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=41324 Summary: ApplicationFilterChain holds references to filters after request ends Product: Tomcat 5 Version: 5.5.20 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] ApplicationFilterChain is holding references to filters after the request. I believe this is because in 5.5.x, ApplicationFilterChain.release() is not nulling out the entries in the filters array. In the 6.0.x trunk, there is a for loop to clear these references. I'll attach a snippet from a JBoss Profiler report from a classloader leakage test I wrote for JBoss. This was from a JBoss build with TC 5.5.20 integrated. It shows the classloader for an undeployed app being held by a chain leading to the Tomcat request processor pool. In an experiment I naively altered the Request.recycle() method to null out the ref to the filter chain and that allowed the classloader to be gc'ed. I see now that adding the for loop to ApplicationFilterFactory.release() is probably the correct solution. This could be a fairly serious classloader leak if the leaked filter references are in a high position in the array; i.e. positions that never get replaced by a subsequent request. In that case the classloader leak would be long lasting. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
