[
https://issues.apache.org/jira/browse/TOMAHAWK-843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12584486#action_12584486
]
Simon Kitching commented on TOMAHAWK-843:
-----------------------------------------
Are you using session-scoped backing beans and component bindings? If so, then
that would cause this problem. And the solution is - don't do that.
MyFaces has been used by some people for large projects, so this is a problem
that is only occuring in some webapps.
I'm not saying that there is not a bug, but that it does not always happen. If
you can attach to this issue a simple webapp that demonstrates this problem (or
even better, a junit test case that demonstrates it) then it will get attention
much faster than if a myfaces developer has to spend time trying to duplicate
this problem on their own...
Re: "not releasing UIComponent memory":
When using server-side state-saving, MyFaces keeps a set of the most recent N
views cached in order to support back-button usage. The default value for N is
20. It keeps extra views in a weakly-referenced cache which might also show up
in profiling, but is not "real" memory use as it will be released if memory is
needed elsewhere. This default value of "20" can be configured - although of
course less back-button presses are then supported. All this is not relevant if
client-side state saving is used; in that case it is up to the browser to cache
old data if it wants back-button to work.
Re: "data table uses lots of memory"
PageContextImpl would be an interesting class to be hogging memory: that is a
JSP tag support class, not a JSF class (it is in org.apache.taglibs.*). Does
anyone know what the role and lifecycle of a PageContext class is?
Are the tables you are having problems with "display-only", or do they contain
input components? A UIData component does not keep a reference to its DataModel
object, but the tree does keep the internal state of any input components.
> myfaces not releasing memory gracefully?
> ----------------------------------------
>
> Key: TOMAHAWK-843
> URL: https://issues.apache.org/jira/browse/TOMAHAWK-843
> Project: MyFaces Tomahawk
> Issue Type: Bug
> Affects Versions: 1.1.3
> Environment: tomcat 5.5.12
> Reporter: Dez
>
> Hi,
> I've been using Myfaces implementation of JSF for couple of months and
> just noticed that memory usage is pretty high - > many times I got out of
> memory error. It works fine for simple pages, but when the page is large and
> complex, it doesn't seem to release the memory used by component states.
> Here is the scenario:
> I'm using t:datatable for rendering employees info. Each row corresponds to
> a employee object, the row has 10 columns.
> It works fine in terms of memory footprint and CPU, when the dataset the
> table renders is small, but when the size of the datasets is large(talking
> about 500 or more), I get Out of memory error even though the Managed Bean
> is request-scoped. No pagination being employed(that's the last resort). So
> when the number of user increases, this leads to a serious issues of server
> crash, hang etc.
> On profiling using yourtoolkit, I found that faces context never releases
> the memory used by UI Components and the behaviour is erratic. The GC kicks
> in after certain stage which is not very useful. Even for a table of small
> data rows(20-30), it doesn't seem to release the memory, in fact it
> accumulates the memory.
> So even the pagination doesn't seem to solve the out- of- memory issue as
> the web site will be used by large number of users. FYI, I'm using the
> client STATE_SAVING_METHOD.
> <context-param>
> <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
> <param-value>client</param-value>
> </context-param>
> Has anyone faced similar issues? Is this a bug or known issues of myfaces?
> No one seem to have resolved this issues, I did see similar issues being
> posted in different forums.
> Would appreciate your help in this regard.
> thanks
> Dezmax
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
