myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simon Kitching (JIRA)" <>
Subject [jira] Commented: (TOMAHAWK-843) myfaces not releasing memory gracefully?
Date Wed, 02 Apr 2008 09:46:25 GMT


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:
>             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
>  <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
>  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.

View raw message