You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Daniel Niklas <co...@dniklas.de> on 2008/09/01 17:21:51 UTC
statesaving - memory consumption
Hi,
i am using server-side state saving (because the environment is a portal). I
noticed a high memory consumption for the view state, or exacting for the
history of old view states. Now i have some questions on this:
1)
Is view state history *only* for "back-Button" of the browser?
2)
There is a (Weak/Soft) ReferenceMap for old view states. Theses instances
comes into old generation memory. I think, the garbage collector must often
clean up these objects. Is this an optimal behavior?
I'm using myfaces 1.1.5. Here the old views are hold with soft references.
Is this working? I found an issue
https://issues.apache.org/jira/browse/MYFACES-1658.
In 1.1.6 the ReferenceMap holds only weak values and keys. Why that?
Best regards
Daniel
--
View this message in context: http://www.nabble.com/statesaving---memory-consumption-tp19256471p19256471.html
Sent from the MyFaces - Users mailing list archive at Nabble.com.
RE: statesaving - memory consumption
Posted by Daniel Niklas <co...@dniklas.de>.
Hi Michael,
thanks for your answer. I'm not quite sure of upgrading to 1.1.6 or
remove the old views map on my own (or both).
Best regards
Daniel
--
View this message in context: http://www.nabble.com/statesaving---memory-consumption-tp19256471p19270418.html
Sent from the MyFaces - Users mailing list archive at Nabble.com.
RE: statesaving - memory consumption
Posted by Michael Heinen <mh...@recommind.com>.
I extended the JspStateManagerImpl also for this reason (and for some
simple multi window support).
I removed the Map with the old views stored as weak references because
they are not useful at all in my App.
Benefit is that GC is more performant and that possible errors (View
could not be restored) are exactly reproducible and do not depend on
memory consumption.
Michael
-----Original Message-----
From: Daniel Niklas [mailto:conti@dniklas.de]
Sent: Dienstag, 2. September 2008 14:33
To: users@myfaces.apache.org
Subject: Re: statesaving - memory consumption
Hi Simon,
Simon Kitching wrote:
>
> The idea is that by setting NUMBER_OF_VIEWS_IN_SESSION, a webapp can
> guarantee to support a certain number of back-button clicks - at the
JSF
> level at least.
>
> Or that when two windows are open on the same webapp, that the user
can
> perform NUMBER_OF_VIEWS_IN_SESSION clicks in one window before the
other
> window starts to misbehave.
>
Ok, our application doesn't need something like that, because we have
session beans...
Simon Kitching wrote:
>
> The "weak" map stuff then tries to make life nice for the user; when
> there is memory to spare then it tries to keep as many old views as
> possible, so that even more than NUMBER_OF_VIEWS_IN_SESSION clicks
will
> work. But when memory is low, only NUMBER_OF_VIEWS_IN_SESSION clicks
are
> guaranteed to work.
>
It might be a problem, that many of these objects are created and
the memory increases very fast. That means much effort for garbage
collection!
And most people (?!) doesn't need this mechanism at all.
Simon Kitching wrote:
>
> The original code used the default constructor for ReferenceMap, which
> uses strong refs to keys but weak refs to values. The key object here
is
> not large; it is the value (which is the whole UIViewRoot) that is
held
> weakly. However nothing *ever* clears the keys for this map.
>
Yes, 1.1.5 uses the default constructor for ReferenceMap. But this
was not the problem! Entries of ReferenceMap will be removed when the
garbage collection runs (and there is no other hard reference to
the value), even if the corresponding key is hardly referenced!
No memory leak here.
Simon Kitching wrote:
>
> I agree with your second posting, a weak references isn't a good
> choice here, soft references would be better, but no idea
> what was going wrong with 1.1.5. I'll check this.
>
Thanks for your answers
Daniel
--
View this message in context:
http://www.nabble.com/statesaving---memory-consumption-tp19256471p192693
23.html
Sent from the MyFaces - Users mailing list archive at Nabble.com.
Re: statesaving - memory consumption
Posted by Daniel Niklas <co...@dniklas.de>.
Hi Simon,
Simon Kitching wrote:
>
> I suspect think there is. A ReferenceMap will have internal data
> structures. I haven't checked the code, but would guess that these are
> only cleaned up when methods are called on the referencemap.
>
Right, this coul'd be a problem. Internally there is a byte array.
This array grows and memory increases for holding the references
in that array - 4/8 bytes per reference (32/64 bit JVM). The
entries of this array are garbage collected, but the size of the
array itself might grow and grow...
(400.000 entries = 2 MB -> "slight leak")
best regards
Daniel
--
View this message in context: http://www.nabble.com/statesaving---memory-consumption-tp19256471p19270321.html
Sent from the MyFaces - Users mailing list archive at Nabble.com.
Re: statesaving - memory consumption
Posted by Simon Kitching <sk...@apache.org>.
Daniel Niklas schrieb:
> Hi Simon,
>
>
> Simon Kitching wrote:
>
>> The idea is that by setting NUMBER_OF_VIEWS_IN_SESSION, a webapp can
>> guarantee to support a certain number of back-button clicks - at the JSF
>> level at least.
>>
>> Or that when two windows are open on the same webapp, that the user can
>> perform NUMBER_OF_VIEWS_IN_SESSION clicks in one window before the other
>> window starts to misbehave.
>>
>>
>
> Ok, our application doesn't need something like that, because we have
> session beans...
>
If you have session-scoped beans, and your users are not prevented from
using the back-button then you *will* have problems.
Note that there are two quite separate issues here:
* having the jsf view correctly restored after "back" button
* having your backing beans correctly handle the user leaping around
the application in unexpected ways (which is what "back" and "forward"
buttons look like to the server code).
The core we are talking about here does solve the first one, but doesn't
even try to solve the second.
>
> Simon Kitching wrote:
>
>> The "weak" map stuff then tries to make life nice for the user; when
>> there is memory to spare then it tries to keep as many old views as
>> possible, so that even more than NUMBER_OF_VIEWS_IN_SESSION clicks will
>> work. But when memory is low, only NUMBER_OF_VIEWS_IN_SESSION clicks are
>> guaranteed to work.
>>
>>
> It might be a problem, that many of these objects are created and
> the memory increases very fast. That means much effort for garbage
> collection!
> And most people (?!) doesn't need this mechanism at all.
>
If you've found a way to stop users using the "back" button, please tell me!
I've found that even threatening them with a large ice axe isn't enough
to keep their paws off that button.
Ordinary users *really* like the idea of "back" as an option.
>
> Simon Kitching wrote:
>
>> The original code used the default constructor for ReferenceMap, which
>> uses strong refs to keys but weak refs to values. The key object here is
>> not large; it is the value (which is the whole UIViewRoot) that is held
>> weakly. However nothing *ever* clears the keys for this map.
>>
>>
>
> Yes, 1.1.5 uses the default constructor for ReferenceMap. But this
> was not the problem! Entries of ReferenceMap will be removed when the
> garbage collection runs (and there is no other hard reference to
> the value), even if the corresponding key is hardly referenced!
> No memory leak here.
>
I suspect think there is. A ReferenceMap will have internal data
structures. I haven't checked the code, but would guess that these are
only cleaned up when methods are called on the referencemap.
Regards,
Simon
Re: statesaving - memory consumption
Posted by Daniel Niklas <co...@dniklas.de>.
Hi Simon,
Simon Kitching wrote:
>
> The idea is that by setting NUMBER_OF_VIEWS_IN_SESSION, a webapp can
> guarantee to support a certain number of back-button clicks - at the JSF
> level at least.
>
> Or that when two windows are open on the same webapp, that the user can
> perform NUMBER_OF_VIEWS_IN_SESSION clicks in one window before the other
> window starts to misbehave.
>
Ok, our application doesn't need something like that, because we have
session beans...
Simon Kitching wrote:
>
> The "weak" map stuff then tries to make life nice for the user; when
> there is memory to spare then it tries to keep as many old views as
> possible, so that even more than NUMBER_OF_VIEWS_IN_SESSION clicks will
> work. But when memory is low, only NUMBER_OF_VIEWS_IN_SESSION clicks are
> guaranteed to work.
>
It might be a problem, that many of these objects are created and
the memory increases very fast. That means much effort for garbage
collection!
And most people (?!) doesn't need this mechanism at all.
Simon Kitching wrote:
>
> The original code used the default constructor for ReferenceMap, which
> uses strong refs to keys but weak refs to values. The key object here is
> not large; it is the value (which is the whole UIViewRoot) that is held
> weakly. However nothing *ever* clears the keys for this map.
>
Yes, 1.1.5 uses the default constructor for ReferenceMap. But this
was not the problem! Entries of ReferenceMap will be removed when the
garbage collection runs (and there is no other hard reference to
the value), even if the corresponding key is hardly referenced!
No memory leak here.
Simon Kitching wrote:
>
> I agree with your second posting, a weak references isn't a good
> choice here, soft references would be better, but no idea
> what was going wrong with 1.1.5. I'll check this.
>
Thanks for your answers
Daniel
--
View this message in context: http://www.nabble.com/statesaving---memory-consumption-tp19256471p19269323.html
Sent from the MyFaces - Users mailing list archive at Nabble.com.
Re: statesaving - memory consumption
Posted by Simon Kitching <sk...@apache.org>.
Simon Kitching schrieb:
> Daniel Niklas schrieb:
>> Hi,
>>
>> i am using server-side state saving (because the environment is a
>> portal). I
>> noticed a high memory consumption for the view state, or exacting for
>> the
>> history of old view states. Now i have some questions on this:
>>
>> 1)
>> Is view state history *only* for "back-Button" of the browser?
>>
> It is also needed to support multiple windows for the same webapp.
> Actually, this doesn't really work properly but having some old view
> states at least makes it work some of the time.
>
> The idea is that by setting NUMBER_OF_VIEWS_IN_SESSION, a webapp can
> guarantee to support a certain number of back-button clicks - at the
> JSF level at least.
>
> Or that when two windows are open on the same webapp, that the user
> can perform NUMBER_OF_VIEWS_IN_SESSION clicks in one window before the
> other window starts to misbehave.
>
> In practice, neither of these are very useful if the application uses
> session-scoped beans of any type as these are not "versioned" like the
> view, and so trying to go "back" to a previous view (or use a separate
> window) while having just one copy of the session-scoped beans is
> usually a problem. An app needs to use only request-scoped beans, or
> Orchestra conversation-scoped beans for this to function correctly.
>
> The "weak" map stuff then tries to make life nice for the user; when
> there is memory to spare then it tries to keep as many old views as
> possible, so that even more than NUMBER_OF_VIEWS_IN_SESSION clicks
> will work. But when memory is low, only NUMBER_OF_VIEWS_IN_SESSION
> clicks are guaranteed to work.
>> 2)
>> There is a (Weak/Soft) ReferenceMap for old view states. Theses
>> instances
>> comes into old generation memory. I think, the garbage collector must
>> often
>> clean up these objects. Is this an optimal behavior?
>>
>> I'm using myfaces 1.1.5. Here the old views are hold with soft
>> references.
>> Is this working? I found an issue
>> https://issues.apache.org/jira/browse/MYFACES-1658.
>>
>> In 1.1.6 the ReferenceMap holds only weak values and keys. Why that?
> I'm not sure what you're asking here. Why do you think that something
> is not working?
>
> The original code used the default constructor for ReferenceMap, which
> uses strong refs to keys but weak refs to values. The key object here
> is not large; it is the value (which is the whole UIViewRoot) that is
> held weakly. However nothing *ever* clears the keys for this map. So
> as the profiling tests referenced in the original email thread show,
> there is a leak: when a single user makes a large number of requests
> in the same session then eventually the number of key objects in the
> map builds up to unreasonably large number. They are small, but enough
> of them add up.
>
> The fix was to use weak refs for the keys as well. And the profiling
> tests showed that this solved the issue.
>
> I suspect that there is a *slight* leak here. Suppose a user performs
> a lot of requests, then stops. The garbage-collector will eventually
> reclaim both the key and value objects from the "old" map. But it
> won't reclaim the Map.Entry objects used by the ReferenceMap itself. I
> presume that these get collected when any method is called on
> ReferenceMap, but as the user is inactive that doesn't happen. So some
> memory is held by the user until the session expires. Probably not a
> problem in practice though.
>
> Is that what you wanted to know?
Hmm..actually, should this map be using SoftReference rather than
WeakReference?
The garbage-collector should collect a WeakReference as soon as it can.
So this cache will almost always be empty. The garbage-collector will
collect a SoftReference only when memory is low. That seems more
appropriate for this kind of cache.
Regards,
Simon
Re: statesaving - memory consumption
Posted by Simon Kitching <sk...@apache.org>.
Daniel Niklas schrieb:
> Hi,
>
> i am using server-side state saving (because the environment is a portal). I
> noticed a high memory consumption for the view state, or exacting for the
> history of old view states. Now i have some questions on this:
>
> 1)
> Is view state history *only* for "back-Button" of the browser?
>
It is also needed to support multiple windows for the same webapp.
Actually, this doesn't really work properly but having some old view
states at least makes it work some of the time.
The idea is that by setting NUMBER_OF_VIEWS_IN_SESSION, a webapp can
guarantee to support a certain number of back-button clicks - at the JSF
level at least.
Or that when two windows are open on the same webapp, that the user can
perform NUMBER_OF_VIEWS_IN_SESSION clicks in one window before the other
window starts to misbehave.
In practice, neither of these are very useful if the application uses
session-scoped beans of any type as these are not "versioned" like the
view, and so trying to go "back" to a previous view (or use a separate
window) while having just one copy of the session-scoped beans is
usually a problem. An app needs to use only request-scoped beans, or
Orchestra conversation-scoped beans for this to function correctly.
The "weak" map stuff then tries to make life nice for the user; when
there is memory to spare then it tries to keep as many old views as
possible, so that even more than NUMBER_OF_VIEWS_IN_SESSION clicks will
work. But when memory is low, only NUMBER_OF_VIEWS_IN_SESSION clicks are
guaranteed to work.
> 2)
> There is a (Weak/Soft) ReferenceMap for old view states. Theses instances
> comes into old generation memory. I think, the garbage collector must often
> clean up these objects. Is this an optimal behavior?
>
> I'm using myfaces 1.1.5. Here the old views are hold with soft references.
> Is this working? I found an issue
> https://issues.apache.org/jira/browse/MYFACES-1658.
>
> In 1.1.6 the ReferenceMap holds only weak values and keys. Why that?
>
I'm not sure what you're asking here. Why do you think that something is
not working?
The original code used the default constructor for ReferenceMap, which
uses strong refs to keys but weak refs to values. The key object here is
not large; it is the value (which is the whole UIViewRoot) that is held
weakly. However nothing *ever* clears the keys for this map. So as the
profiling tests referenced in the original email thread show, there is a
leak: when a single user makes a large number of requests in the same
session then eventually the number of key objects in the map builds up
to unreasonably large number. They are small, but enough of them add up.
The fix was to use weak refs for the keys as well. And the profiling
tests showed that this solved the issue.
I suspect that there is a *slight* leak here. Suppose a user performs a
lot of requests, then stops. The garbage-collector will eventually
reclaim both the key and value objects from the "old" map. But it won't
reclaim the Map.Entry objects used by the ReferenceMap itself. I presume
that these get collected when any method is called on ReferenceMap, but
as the user is inactive that doesn't happen. So some memory is held by
the user until the session expires. Probably not a problem in practice
though.
Is that what you wanted to know?
Regards,
Simon