wbirkhead schrieb: > Gerald Müllan-2 wrote: > >> However, the JspStateManagerImpl holds *all* the views in the session >> - regardless the setting - but with a weak reference. Means it will be >> freed out of the memory if gc determines that memory consumption is >> high. >> >> > > Gerald, is this the intended functionality of myfaces state manager? I am > seeing very similar profiling results, and my problem is coming when I > increase the number of users. I am seeing WAY too many gc's per request > which is slowing everything down. I tried dropping my number of views in > session to 3 and still saw the issue. Is this a known issue, or could I be > misusing Myfaces? >
The whole point of this viewstate cache is to support backbutton usage. When configured to hold N views per session, it then supports the user pressing the backbutton N times. This pool is kept using strong references. The pool is a least-recently-used list; when things are removed from the pool (to keep its size at N), they are moved to a pool that uses weak refs. This allows more-than-N backbutton clicks to work when memory pressure is low - or at least that is the intention. Using back-buttons in JSF apps is actually fairly broken for other reasons, so it isn't very useful [1]. Quite how a JVM interacts with weakrefs when memory pressure exists is up to the JVM implementation. But at least theoretically it can reclaim it all. Unless there is a bug (and I don't know of one), a pool of size 3 shouldn't cause major system problems, unless the object you're using with t:saveState is very large. If it is large, then you might want to consider using a proper conversation-scope, like Orchestra or Spring WebFlow or Seam, which will not keep one copy per cached viewtree. Regards, Simon
