[
https://issues.apache.org/jira/browse/MYFACES-3924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14127518#comment-14127518
]
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: https://issues.apache.org/jira/browse/MYFACES-3924
> 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
(v6.3.4#6332)
