RichFaces - restoreView and createView

[bek816]

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

[bek816]

Can anyone with in depth knowledge of the inner workings of RichFaces explain to me how/why RichFaces 'caches' view roots? As I illustrated above, this has led to all sorts of migration problems. I'd be very curious to know if this is configurable. I.e. can I tell RichFaces to stop caching all of these view roots? Or at least, I'd like to know how many view roots RichFaces caches. We've noticed a huge increase in heap size.

Thanks.

[alexsmirnov]

I've created simple RichFaces sample, and run it under debugger.
In the all navigation cases ( both AJAX and form submit ), restoreView have never been called for a second page.
Even more, we have own StateManager and ViewHandler implementations, but don't make any modifications in the JSF LifeCycle.
What is JSF implementation in the your application ? Do you have any additional libraries ( Seam, Tomahawk etc )?

[bek816]

Hi alexsmirnov,

Good morning! Thanks for doing some research on this. It's appreciated!

To answer your question, we use the following libraries:

RichFaces 3.1.4
MyFaces 1.1.4
Tomahawk 1.1.2
Jsps / Tiles
Jenia (commons, dynamic, and popup) 1.2.1
ChartCreator 1.2.0
Dwr 1.1.3

Outside of those web libraries, we use Spring, Hibernate, etc.

Thanks.

-Brian