You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Ate Douma (JIRA)" <ji...@apache.org> on 2007/11/05 17:52:50 UTC

[jira] Closed: (WICKET-1129) ThreadLocal leak in new RequestContext code prevents clean undeploy of Wicket application

     [ https://issues.apache.org/jira/browse/WICKET-1129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ate Douma closed WICKET-1129.
-----------------------------


Solution seems fine by me, and for this "context" the portlet side of things are just the same.

> 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.