[
https://issues.apache.org/jira/browse/MYFACES-2942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12922378#action_12922378
]
Leonardo Uribe commented on MYFACES-2942:
-----------------------------------------
Hi
It is good to use FacesContext attribute map instead (anyway
FacesContext.getCurrentInstance uses a ThreadLocal var, but it is correctly
cleaned after request ends), but I'm not agree with remove all ThreadLocal
instances, because that's not the problem. The problem is add code that "clean"
those instances where it is required.
There are valid cases where ThreadLocal usage is required. For example, in
FlashELResolver it is possible that an EL expression could be resolved outside
normal JSF lifecycle, where there is no FacesContext set, so the code committed
will not work as expected. The same applies for VariableResolverToELResolver,
so that code must be reverted to its original form.
I see that my suggestion about "clear" the map was not very clear. I was
thinking on add some code inside
org.apache.myfaces.webapp.AbstractFacesInitializer.destroyFaces(ServletContext)
to do proper cleanup (if you have a WeakHashMap somewhere, call a method that
removes the key).
For the case of MetaRulesetImpl, I think use a WeakHashMap and do proper
cleanup on AbstractFacesInitializer.destroyFaces is better. There is no reason
to call FacesContext.getCurrentInstance(), since the returned instances are
"application scope" and once initialized does not change.
> Memory Leak in MyFaces 2.0.1 probably as well in 2.0.2
> ------------------------------------------------------
>
> Key: MYFACES-2942
> URL: https://issues.apache.org/jira/browse/MYFACES-2942
> Project: MyFaces Core
> Issue Type: Bug
> Affects Versions: 2.0.1, 2.0.2
> Environment: JBOSS AS
> Reporter: Werner Punz
> Assignee: Jakob Korherr
> Priority: Critical
> Attachments: MYFACES-2942-RuntimeConfig.patch
>
>
> Stan Silvert from JBoss reports:
> I'm pretty sure 2.0.1 has a memory leak on undeploy. Mojarra had an undeploy
> leak and it took a long time to track it down. The same test I was using on
> Mojarra also failed on MyFaces but I haven't had time to track down the leak
> in MyFaces.
> Maybe this is fixed in 2.0.2? If not maybe someone can go ahead and take a
> look? The mem leak keeps MyFaces from passing TCK on JBoss AS. To test, all
> you need to do is create a small exploaded JSF app. Then have a script that
> touches web.xml every 10 seconds. That will cause the app to redeploy. You
> will get a PermGen error in about an hour.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
