Lukas Krejci commented on RF-3878:
our solution was to reduce those parameters to 2 and to optimize the size of the UI beans
we create. Bear in mind that even the request scoped beans are still referenced by the
views that are stored in the session this way so they are not garbage collected.
That was actually our problem. We had a big request scoped bean (the above referenced
ResourceTreeModelUIBean) which was recreated for each view and then a number of such views
were stored in session. So apart from reducing the number of views that we store in the
session we minimized the memory usage of that bean.
Not sure if the request scoped beans are only kept around if they are marked as
"keep-alive" (which they are in our case) or if they stay referenced by the
stored views in any case.
Session memory leak
Issue Type: Bug
Security Level: Public(Everyone can see)
Affects Versions: 3.2.0.SR1
Reporter: Dmitri Voronov
Assignee: Nick Belaevski
Fix For: 3.3.0
AjaxStateHolder saves all views in the session. But the same view can occur several times
in this "cache"; the views from this "cache" are not reused and just
fill the session. If an application has many large views and deals with many concurrent
sessions, the heap can easily grow up to Gigabytes(!)
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see: http://www.atlassian.com/software/jira