[ http://jira.jboss.com/jira/browse/RF-2292?page=all ] Alexander Smirnov resolved RF-2292. ----------------------------------- Resolution: Done In the RichFaces 3.2.0 branch, AjaxStateManager using same SUN RI configuration parameters. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/RF-2292?page=all ] Aleksej Yanul reassigned RF-2292: --------------------------------- Assignee: Aleksej Yanul (was: Alexander Smirnov) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/RF-2292?page=com.atlassian.jira.plugin... ] 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. 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 -- 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