You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by se...@globecast.com on 2008/03/28 17:29:40 UTC
Leak in saveState?
Hi,
Using MessAdmin, I noticed that the size of the attribute
'org.apache.myfaces.application.jsp.JspStateManagerImpl.SERIALIZED_VIEW' in
session is continualy increasing. Approximately 100K by viewed page.
It appears with myfaces1.1.5 and tomahawk 1.1.4-SNAPSHOT but with
myfaces1.2.2 and tomahawk 1.1.6 too.
Any ideas?
Thanks.
Sébastien Clément
Re: Leak in saveState?
Posted by jimmyau <ji...@privasia.com>.
u think i got chance or not??
----- Original Message -----
From: "Gerald Müllan" <gm...@apache.org>
To: "MyFaces Discussion" <us...@myfaces.apache.org>
Sent: Saturday, March 29, 2008 8:15 PM ii
Subject: Re: Leak in saveState?
> Hi,
>
>> Using MessAdmin, I noticed that the size of the attribute
>> 'org.apache.myfaces.application.jsp.JspStateManagerImpl.SERIALIZED_VIEW'
>> in
>> session is continualy increasing. Approximately 100K by viewed page.
>
> yes;
>
> With the web.xml setting org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION
> you can influence the amount of stored views in the session in order
> to restore them when navigating with the back button.
>
> 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.
>
> Because of this, the tool recognizes increasing memory consumption.
>
> cheers,
>
> Gerald
>
> --
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG.
> Version: 7.5.519 / Virus Database: 269.22.1/1348 - Release Date: 3/28/2008
> 10:58 AM
>
>
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Re: Leak in saveState?
Posted by Matthias Wessendorf <ma...@apache.org>.
Michael,
On Fri, Apr 18, 2008 at 5:30 PM, Michael Heinen <mh...@recommind.com> wrote:
> How do you plug-in an own state manager?
> I am right now also playing in this area and removed the weak references.
you can create your own. It has to extend
"javax.faces.application.StateManager".
When done, just register it in the faces-config.xml, like:
<application>
<state-manager>my.own.cool.StateManagerImpl</state-manager>
</application>
-Matthias
>
> Michael
>
>
> -----Original Message-----
> From: bierbrauen@gmail.com [mailto:bierbrauen@gmail.com] On Behalf Of Gerald Müllan
> Sent: Freitag, 18. April 2008 17:13
> To: MyFaces Discussion
> Subject: Re: Leak in saveState?
>
>
>
> Hi Simon,
>
> i think he has meant that gc is running too many times and slows the
> system down when the weak refs are getting very high.
> Which in turn occurs when many users have been interacting with the
> application and therefore many views have been stored.
>
> Well, maybe the approach with the weak references has to be
> overhauled. I recently did some stuff with periodically fired ajax
> requests
> and recognized a kind of system freeze with 20 + users after some
> time. After some profiling i was aware of the weak references
> which raised to a huge amount. Per user 3-4 areas are refreshed some
> times, each few seconds. Many many views are stored weak in
> this case.
>
> I plugged in my own StateManager without the weak references and the
> problem seems to be gone. Sure thing, this ajax
> scenario is not common, but it seems to show a major drawback.
>
> cheers,
>
> Gerald
>
> --
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
>
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
RE: Leak in saveState?
Posted by Michael Heinen <mh...@recommind.com>.
How do you plug-in an own state manager?
I am right now also playing in this area and removed the weak references.
Michael
-----Original Message-----
From: bierbrauen@gmail.com [mailto:bierbrauen@gmail.com] On Behalf Of Gerald Müllan
Sent: Freitag, 18. April 2008 17:13
To: MyFaces Discussion
Subject: Re: Leak in saveState?
Hi Simon,
i think he has meant that gc is running too many times and slows the
system down when the weak refs are getting very high.
Which in turn occurs when many users have been interacting with the
application and therefore many views have been stored.
Well, maybe the approach with the weak references has to be
overhauled. I recently did some stuff with periodically fired ajax
requests
and recognized a kind of system freeze with 20 + users after some
time. After some profiling i was aware of the weak references
which raised to a huge amount. Per user 3-4 areas are refreshed some
times, each few seconds. Many many views are stored weak in
this case.
I plugged in my own StateManager without the weak references and the
problem seems to be gone. Sure thing, this ajax
scenario is not common, but it seems to show a major drawback.
cheers,
Gerald
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
RE: Leak in saveState?
Posted by Michael Heinen <mh...@recommind.com>.
I had to remove the sequence id in my custom JspStateManager.
The app did not work anymore with parallel ajax requests after removing the map with the old views (weakReferences)
Shouldn't this be officially supported in myFaces?
e.g. if back button is not supported (numberOfViewsInSession=1) then another JspStateManager without sequence ids should be used.
From my point of view the Map containing the old views as weakReferences should also be removed because it results in really unpredictable behavior under load and it costs performance.
Michael
-----Original Message-----
From: Michael Heinen [mailto:mhn@recommind.com]
Sent: Dienstag, 22. April 2008 11:11
To: MyFaces Discussion
Subject: RE: Leak in saveState?
Hi,
I removed also the map containing the old views as weak references.
It does not make any sense in my use case because my app does not support the browser back button.
Moreover I think that this map with the weak references results in unpredictable behavior under load.
I am facing now a new problem without this old views caused by the sequence id in the SerializedViewKey.
If I define numberOfViewsInSession=1 and a page is submitted multiple times with ajax then let's say request1 and reqest2 are submitted with sequenceId=1.
This sequenceId is increased during processing of request1 from 1 to 2.
The view of request2 can't be restored anymore because it is fired with sequenceId1 but the session counter is at 2!
Therefore my question:
Can I remove the sequenceId from SerializedViewKey if I do not support browser back button?
From my point of view the weakMap and the sequenceId should not be used in case of numberOfViewsInSession=1
Michael
-----Original Message-----
From: simon.kitching@chello.at [mailto:simon.kitching@chello.at]
Sent: Montag, 21. April 2008 16:37
To: MyFaces Discussion
Subject: Re: Leak in saveState?
wbirkhead schrieb:
> Gerald Müllan-3 wrote:
>
>>> I can see that in some cases it may help, perhaps you wanna share the
>>>
>> impl ?
>>
>> I just removed the two lines with the weak references. So, only ugly
>> duplication of code. :)
>>
>>
>>
>
> Gerald, at the risk of sounding like a novice, can you point me to the lines
> of code with the weak references that you mention above? This would be a
> HUGE help.
>
JspStateManagerImpl has this method:
public synchronized void add(FacesContext context, Object state)
{
Object key = new SerializedViewKey(context);
_serializedViews.put(key, state);
while (_keys.remove(key));
_keys.add(key);
int views = getNumberOfViewsInSession(context);
while (_keys.size() > views)
{
key = _keys.remove(0);
Object oldView = _serializedViews.remove(key);
if (oldView != null)
{
getOldSerializedViewsMap().put(key, oldView);
}
}
}
The second while loop is trimming the "strong-referenced" pool down to
the necessary size, and adding the removed entries into the weak pool.
So just commenting out the call to
getOldSerializedViewsMap().put(key, oldView);
should do the trick.
Regards,
Simon
RE: Leak in saveState?
Posted by Michael Heinen <mh...@recommind.com>.
Hi,
I removed also the map containing the old views as weak references.
It does not make any sense in my use case because my app does not support the browser back button.
Moreover I think that this map with the weak references results in unpredictable behavior under load.
I am facing now a new problem without this old views caused by the sequence id in the SerializedViewKey.
If I define numberOfViewsInSession=1 and a page is submitted multiple times with ajax then let's say request1 and reqest2 are submitted with sequenceId=1.
This sequenceId is increased during processing of request1 from 1 to 2.
The view of request2 can't be restored anymore because it is fired with sequenceId1 but the session counter is at 2!
Therefore my question:
Can I remove the sequenceId from SerializedViewKey if I do not support browser back button?
From my point of view the weakMap and the sequenceId should not be used in case of numberOfViewsInSession=1
Michael
-----Original Message-----
From: simon.kitching@chello.at [mailto:simon.kitching@chello.at]
Sent: Montag, 21. April 2008 16:37
To: MyFaces Discussion
Subject: Re: Leak in saveState?
wbirkhead schrieb:
> Gerald Müllan-3 wrote:
>
>>> I can see that in some cases it may help, perhaps you wanna share the
>>>
>> impl ?
>>
>> I just removed the two lines with the weak references. So, only ugly
>> duplication of code. :)
>>
>>
>>
>
> Gerald, at the risk of sounding like a novice, can you point me to the lines
> of code with the weak references that you mention above? This would be a
> HUGE help.
>
JspStateManagerImpl has this method:
public synchronized void add(FacesContext context, Object state)
{
Object key = new SerializedViewKey(context);
_serializedViews.put(key, state);
while (_keys.remove(key));
_keys.add(key);
int views = getNumberOfViewsInSession(context);
while (_keys.size() > views)
{
key = _keys.remove(0);
Object oldView = _serializedViews.remove(key);
if (oldView != null)
{
getOldSerializedViewsMap().put(key, oldView);
}
}
}
The second while loop is trimming the "strong-referenced" pool down to
the necessary size, and adding the removed entries into the weak pool.
So just commenting out the call to
getOldSerializedViewsMap().put(key, oldView);
should do the trick.
Regards,
Simon
Re: Leak in saveState?
Posted by "simon.kitching@chello.at" <si...@chello.at>.
wbirkhead schrieb:
> Gerald Müllan-3 wrote:
>
>>> I can see that in some cases it may help, perhaps you wanna share the
>>>
>> impl ?
>>
>> I just removed the two lines with the weak references. So, only ugly
>> duplication of code. :)
>>
>>
>>
>
> Gerald, at the risk of sounding like a novice, can you point me to the lines
> of code with the weak references that you mention above? This would be a
> HUGE help.
>
JspStateManagerImpl has this method:
public synchronized void add(FacesContext context, Object state)
{
Object key = new SerializedViewKey(context);
_serializedViews.put(key, state);
while (_keys.remove(key));
_keys.add(key);
int views = getNumberOfViewsInSession(context);
while (_keys.size() > views)
{
key = _keys.remove(0);
Object oldView = _serializedViews.remove(key);
if (oldView != null)
{
getOldSerializedViewsMap().put(key, oldView);
}
}
}
The second while loop is trimming the "strong-referenced" pool down to
the necessary size, and adding the removed entries into the weak pool.
So just commenting out the call to
getOldSerializedViewsMap().put(key, oldView);
should do the trick.
Regards,
Simon
Re: Leak in saveState?
Posted by wbirkhead <wb...@gmail.com>.
Gerald Müllan-3 wrote:
>
>> I can see that in some cases it may help, perhaps you wanna share the
> impl ?
>
> I just removed the two lines with the weak references. So, only ugly
> duplication of code. :)
>
>
Gerald, at the risk of sounding like a novice, can you point me to the lines
of code with the weak references that you mention above? This would be a
HUGE help.
Thanks,
- Will
--
View this message in context: http://www.nabble.com/Leak-in-saveState--tp16356703p16807937.html
Sent from the MyFaces - Users mailing list archive at Nabble.com.
Re: Leak in saveState?
Posted by Gerald Müllan <ge...@gmail.com>.
Hi,
> maybe comet would help here, instead of heavily pinging the server ;-)
Yes, i am aware of comet but in our case it was for some reason not
meaningful to use it.
> I can see that in some cases it may help, perhaps you wanna share the
impl ?
I just removed the two lines with the weak references. So, only ugly
duplication of code. :)
cheers,
Gerald
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: Leak in saveState?
Posted by Matthias Wessendorf <ma...@apache.org>.
> i think he has meant that gc is running too many times and slows the
> system down when the weak refs are getting very high.
> Which in turn occurs when many users have been interacting with the
> application and therefore many views have been stored.
>
> Well, maybe the approach with the weak references has to be
> overhauled. I recently did some stuff with periodically fired ajax
> requests
> and recognized a kind of system freeze with 20 + users after some
maybe comet would help here, instead of heavily pinging the server ;-)
> time. After some profiling i was aware of the weak references
> which raised to a huge amount. Per user 3-4 areas are refreshed some
> times, each few seconds. Many many views are stored weak in
> this case.
>
> I plugged in my own StateManager without the weak references and the
> problem seems to be gone. Sure thing, this ajax
> scenario is not common, but it seems to show a major drawback.
I can see that in some cases it may help, perhaps you wanna share the
impl ?
-M
>
>
>
> cheers,
>
> Gerald
>
> --
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
Re: Leak in saveState?
Posted by Gerald Müllan <gm...@apache.org>.
Hi Simon,
i think he has meant that gc is running too many times and slows the
system down when the weak refs are getting very high.
Which in turn occurs when many users have been interacting with the
application and therefore many views have been stored.
Well, maybe the approach with the weak references has to be
overhauled. I recently did some stuff with periodically fired ajax
requests
and recognized a kind of system freeze with 20 + users after some
time. After some profiling i was aware of the weak references
which raised to a huge amount. Per user 3-4 areas are refreshed some
times, each few seconds. Many many views are stored weak in
this case.
I plugged in my own StateManager without the weak references and the
problem seems to be gone. Sure thing, this ajax
scenario is not common, but it seems to show a major drawback.
cheers,
Gerald
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: Leak in saveState?
Posted by "simon.kitching@chello.at" <si...@chello.at>.
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
Re: Leak in saveState?
Posted by wbirkhead <wb...@gmail.com>.
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?
Thanks.
- Will
--
View this message in context: http://www.nabble.com/Leak-in-saveState--tp16356703p16763422.html
Sent from the MyFaces - Users mailing list archive at Nabble.com.
Re: Leak in saveState?
Posted by Gerald Müllan <gm...@apache.org>.
Hi,
> Using MessAdmin, I noticed that the size of the attribute
> 'org.apache.myfaces.application.jsp.JspStateManagerImpl.SERIALIZED_VIEW' in
> session is continualy increasing. Approximately 100K by viewed page.
yes;
With the web.xml setting org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION
you can influence the amount of stored views in the session in order
to restore them when navigating with the back button.
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.
Because of this, the tool recognizes increasing memory consumption.
cheers,
Gerald
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: Leak in saveState?
Posted by Werner Punz <we...@gmail.com>.
This sounds more like
the saveState history is turned on.
Does this increase max out after a while?
MyFaces (and the RI) have state histories
which can be turned on which allow a certain number
of old states to be stacked and rolled back
once the back button is pressed.
Werner
sebastien.clement@globecast.com schrieb:
> Hi,
>
> Using MessAdmin, I noticed that the size of the attribute
> 'org.apache.myfaces.application.jsp.JspStateManagerImpl.SERIALIZED_VIEW'
> in session is continualy increasing. Approximately 100K by viewed page.
> It appears with myfaces1.1.5 and tomahawk 1.1.4-SNAPSHOT but with
> myfaces1.2.2 and tomahawk 1.1.6 too.
> Any ideas?
>
> Thanks.
>
>
> *Sébastien Clément*
>