[
https://jira.jboss.org/jira/browse/RF-2292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12424486#action_12424486
]
Brian Kates commented on RF-2292:
---------------------------------
What about the 3.1.x branch? How can we limit the number of view roots in
session? If the views are limited, does that mean it would go through
CreateView rather than RestoreView? That would be consistent with what we saw
prior to migrating to RichFaces.
>From the RichFaces development forum:
Further to my issue below with duplicate id exceptions
(http://jboss.com/index.html?module=bb&op=viewtopic&t=140132), I have some
questions regarding RichFaces restoreView and createView methods. My question
is this: how does RichFaces decide to call restoreView or createView in the
view handler?
Example: I am on page "A" and I navigate to page "B".
Without RichFaces: restoreView is called for page "A" and createView for page
"B". This pattern is consistent. The page that we're leaving is restored and
the page we're going to is created.
RichFaces behaviour: Like the non-RichFaces behaviour, restoreView is called
on page "A" (the page I am leaving), but the behaviour differs for page "B".
If this is my first time going to the page, createView is called. If I have
already been to the page, restoreView is called.
The implication that we discovered is that RichFaces seems to be caching old
view roots. This explains a few things:
1) The duplicate id exceptions I was encountering. It always bugged me that I
would only encounter the exception the second time the page loaded. If their
truly was a duplicate id, it shouldn't render at all.
2) Increased memory consumption. We started seeing out of heap space
exceptions. No wonder - RichFaces is "caching" every view root!
3) A duplicate id exception when a different section is rendered, for example:
<h:outputText id="myId" rendered="{my condition}" />
<h:outputText id="myId" rendered="{not my condition}" />
In the case above, when the condition switches from true to false, RichFaces
would throw a duplicate id exception. At the time I wondered why because only
one would ever be in the view root, but now given RichFaces view root
"caching", it makes sense!
Questions:
1) Why is RichFaces holding onto and restoring old view roots rather than
always creating new?
2) What are the performance and memory impacts? We've already had to bump up
our heap size.
3) How long does RichFaces hold on to the view roots for? When do they
"expire"?
4) Is this a memory leak?
5) Can this be configured?
We are using RichFaces 3.1.4
> numberOfViewsInSession and numberOfLogicalViews is ignored by AjaxStateManager
> ------------------------------------------------------------------------------
>
> Key: RF-2292
> URL: https://jira.jboss.org/jira/browse/RF-2292
> Project: RichFaces
> Issue Type: Bug
> Affects Versions: 3.1.4
> Environment: WinXP, JBoss Portal Server 2.6.2, Sun JDK 1.5, JSF-RI 1.2
> Reporter: Mike
> Assignee: Aleksej Yanul
> Fix For: 3.2.0, 3.2.1
>
>
> Although we set
> <context-param>
> <param-name>com.sun.faces.numberOfViewsInSession</param-name>
> <param-value>2</param-value>
> </context-param>
> and
> <context-param>
> <param-name>com.sun.faces.numberOfLogicalViews</param-name>
> <param-value>2</param-value>
> </context-param>
> The AjaxStateManager.VIEW_STATES_MAP holds 15 Elements, till it drops some!
> Are the numberOfViewsInSession and numberOfLogicalViews ignored?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
richfaces-issues mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/richfaces-issues
