[
https://issues.apache.org/jira/browse/WICKET-1129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Johan Compagner resolved WICKET-1129.
-------------------------------------
Resolution: Fixed
Fix Version/s: 1.3.0-rc2
Assignee: Ate Douma
i think i have fixed it all, introduced a unset on the RequestContext class and
called it in all the places i could think off.
Ate its part of the Portlet stuff so could you give it a quick look an then
close this issue?
> ThreadLocal leak in new RequestContext code prevents clean undeploy of Wicket
> application
> -----------------------------------------------------------------------------------------
>
> Key: WICKET-1129
> URL: https://issues.apache.org/jira/browse/WICKET-1129
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.3.0-beta4
> Environment: Tomcat 5.5.23, Wicket 1.3.0-beta4
> Reporter: Max Bowsher
> Assignee: Ate Douma
> Fix For: 1.3.0-rc2
>
>
> Analyzing heap dumps of Tomcat running my Wicket webapp shows that the webapp
> ClassLoader is not becoming unreferenced and garbage-collectable when the
> webapp is undeployed. The cause is the RequestContext ThreadLocal - this
> ThreadLocal is *not* being cleared before the WicketFilter returns control to
> Tomcat - as a result, Wicket RequestContext instances remain attached to
> Tomcat theadpool threads. Thus the reference chain of Thread ->
> threadLocalsMap -> RequestContext instance prevents the JVM from unloading
> the undeployed webapp classes.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.