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
