myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leonardo Uribe (JIRA)" <>
Subject [jira] [Commented] (MYFACES-3924) Memory leak in ViewScopeBeanHolder
Date Tue, 09 Sep 2014 20:41:28 GMT


Leonardo Uribe commented on MYFACES-3924:

I see. We can't replace that part with remove, because it is possible to have references to
beans before destroy, so the best in this case is wrap the code in a try/finally block.

The spec says that the view scope beans are discarded when the session ends, and the code
do that. But this special block is used to discard views when "server" state saving mode is
used, aiming to keep the session size as small as possible (this is something MyFaces specific).
In reality it will not be a leak, because in practice the sessions will be discarded and with
that the leak will be gone, but anyway the fix is valid, so I have committed it. 

Thanks to Dan Østerberg for the report. 

> Memory leak in ViewScopeBeanHolder
> ----------------------------------
>                 Key: MYFACES-3924
>                 URL:
>             Project: MyFaces Core
>          Issue Type: Bug
>    Affects Versions: 2.2.4
>         Environment: Wildfly 8.1.0.Final
>            Reporter: Dan Østerberg
> When running som stress tests, we noticed a severe memory leak, which causes our server
to crash witin a few minutes when under pressure. It works fine on Mojarra (2.2.8). Our views
aren't particularly big, but we do attach some JPA entities to our ViewScoped beans and we
thus need them to be cleaned up in reasonable time.
> The views are destroyed properly, but field "storageMap" in org.apache.myfaces.cdi.view.ViewScopeBeanHolder
holds onto the references, preventing view state & beans from being GCed.
> To us, the problem seems to be as easy as that method ViewScopeBeanHolder.destroyBeans(String)
doesn't remove the destroyed ViewScopeContextualStorage from the map. Simply replacing the
initial "storageMap.get(viewScopeId)" with "storageMap.remove(viewScopeId)" in that method
solves the memory leak. But maybe there is a reason for not doing so..?

This message was sent by Atlassian JIRA

View raw message