Trinidad StateManagerImpl doesn't clean up UIViewRoot instances when navigating
from a page using a GET
-------------------------------------------------------------------------------------------------------
Key: TRINIDAD-1193
URL: https://issues.apache.org/jira/browse/TRINIDAD-1193
Project: MyFaces Trinidad
Issue Type: Bug
Affects Versions: 1.2.9-core, 1.0.9-core
Environment: Affects all environments
Reporter: Blake Sullivan
The Trinidad StateManagerImpl optimizes state management by caching UiViewRoot
instances in the StateManagerImpl$PageState objects. When restoring a view
with a cached UIViewRoot instance, the StateManagerImpl clones the UIViewRoot
instance and then moves the child component references from the old UIViewRoot
instance to the new UIViewRoot instance and then nulls out the cached
UIViewRoot. When teh request completes, a new PageState instance with the
state of the response UiViewRoot is created. As long as POSTs are used (so
that popView() is called and the old UIViewRoot instance is nulled out, this
scheme works well and allows mutiple windows to have their own cached
UIViewRoot instances (as long as they are viewing different view ids).
However, if the user leaves the current page using any scheme other than a
POST, the UIViewRoot instance is never nulled out and the token cache becomes
populated with non-active PageStates that are still holding onto their
UIViewRoot instances, causing the Session storage to bloat.
The fix guarantees that only the most recently used PageState has its
UIViewRoot by aggressively clearing the UIViewRoots of the last used PageState
when saving the new PageState. The downside is that when multiple windows are
used by a user, only the most recently used window has the state saving
optimization, but the performance penalty is small and only occurs when users
switch windows.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
