ViewExpiredException: (Myfaces1.2.6 and Richfaces3.3.0) Possible problem and solution discussion.

[Rajneesh Kumar Rajput]

I have posted same article in Rich Faces forum, still waiting for answer. Anyways, what I found is related to Rich Faces class, but just want to confirm the usage of saving images in view state map. Please see below...

We recently upgraded Rich Faces to 3.3.0 along with my faces 1.2.6.

We were facing a problem that if we access the application first time, first page gets render properly but further it does not work. But we simply relogin into application again there after same set of pages work fine.

Please see what we found in this.

Initial configurations were as follows..
javax.faces.STATE_SAVING_METHOD=server
org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION = 4

Always, if we use new browser / (Clean browser cache) and login into application first page is rendered properly. But, if we click any of the link on this page then ViewExpiredException is thrown because in the post back request required view id is not available in the server cached views list.

I debug the code and found couple of facts,

1) AjaxStateHolder class uses ContextInitParameters class to rely on the no. of views to store in a session and expects a new context param ' com.sun.faces.numberOfViewsInSession ' to be declare in the web.xml.

Now, we can explains what happens is while doing login browser sends up lots of request to server for page as well as for every image which is being displayed, or style sheets or js files etc.

And, sever stores up each request generated view in the same 'views' list which it is holding for pages. So, images etc are replacing the page view in the list for the first time as there were around total 25 requests are generating in our case for the cleaned browser.

After this, we do login second time and browser does not send separate requests for images and css as those are cached at browser end, so pages works fine because only one view (actual view for the page) get stored and it is available when it is required in immediate post back request.

Proposed Solution 1:

I am not sure, why AjaxStateHolder is storing every resource generated view in the same views list. Request, which are made for images, css and scripts should not be stored in the views state map.

Is this correct to store images, css and scripts in the same view state map or can I put a check on this chunk of code not to put images, css and scripts in the [b]AjaxStateHolder view state map ? [/b].

If it is really not required to store images, css and scripts in the same view state map, this will solve our problem completely.

Well, I didn't check the old version code for myfaces how it was handling this, whether it was storing the images and css etc in the same view state map or not but we never faced this problem in older version of my faces and rich faces.


Proposed Solution 2 [Temporarily]: I can set up com.sun.faces.numberOfViewsInSession variable to a high no. i.e. 25 which is the exact in our case and it will work fine. But, if I increase any image on the same first page and this problem could come again in front of us.

[Robert Filipczyk]

And what if You change state saving method to client?

javax.faces.STATE_SAVING_METHOD=client

I think that when You will use sun jsf, everything will be ok. This kind of problem only co-exists with myfaces.

[Rajneesh Kumar Rajput]

Robert Filipczyk wrote:And what if You change state saving method to client?

javax.faces.STATE_SAVING_METHOD=client

I think that when You will use sun jsf, everything will be ok. This kind of problem only co-exists with myfaces.

Yes, I agree that using the Client will solve this problem at all. But, I do want to keep the state saving method as server as it has other benefits and in past we have change this to server deliberately.

Actually, I am looking for the problem that as I found above rich faces class throws an exception in case if view is not found for a post back request, but myfaces original class does not throw an exception instead it creates a view in this case.

So, more or less either exception should not be thrown because no. of views are limited as those can be configured or these possible irrelevant views i.e. for images or css should not be kept in the same map which for actual page views if I am correct. please provide your views.

[Fernando Franzini]

Hi Rajneesh

I'm with this problems.....so if I raise the org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION to 500 it gona resolve ??
Do you find any correct solution ?
Regards.

[Rajneesh Kumar Rajput]

Fernando Franzini wrote:Hi Rajneesh

I'm with this problems.....so if I raise the org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION to 500 it gona resolve ??
Do you find any correct solution ?
Regards.

Fernando Franzini wrote:Hi Rajneesh

I'm with this problems.....so if I raise the org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION to 500 it gona resolve ??
Do you find any correct solution ?
Regards.

Hi Franzini,
please note if you are using new rich faces i.e. 3.3.0 and myfaces 1.2.6 then org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION is irrelevant and will not be used to configure page views by the server. Rich Faces, expects a new variable i.e. com.sun.faces.numberOfViewsInSession to be set in the web.xml.

Also, if you set its value to 500 , this is again going to a respective solution you still can get an exception if your first page has 501 distinct images to be shown on cleaned cache browser for the first time. I would suggest don't increase this page view map size to 500 as you might encounter other problems in the application is long run if application usage is high and pages are big server needs to maintain page state for lass 500 used pages which is not memory efficient at all.

either go with client state or just calculate how many distinct requests are being made to server including images and css then just set that no. In my case it was 25. Also, this problem only occurs for the very first page because on cleaned browser there is no history/cache available so it just send request for every image and css to server and get it cached on server.

I am also looking if there might be another standard way to add css or images, which can automatically solve this problem. but still looking nothing in hand right now.

[Fernando Franzini]

Hi Rajneesh

I'm using RichFaces 3.2.2 and MyFaces 1.2.2....and my configuration was

<context-param>
<param-name>javax.faces.STATE_SAVING_METHOD</param-name>
<param-value>server</param-value>
</context-param>
<context-param>
<param-name>org.apache.myfaces.SERIALIZE_STATE_IN_SESSION</param-name>
<param-value>false</param-value>
</context-param>
<context-param>
<param-name>org.apache.myfaces.COMPRESS_STATE_IN_SESSION</param-name>
<param-value>false</param-value>
</context-param>
<context-param>
<param-name>org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION</param-name>
<param-value>200</param-value>
</context-param>
<context-param>
<param-name>org.ajax4jsf.handleViewExpiredOnClient</param-name>
<param-value>true</param-value>
</context-param>
<context-param>
<param-name>com.sun.faces.enableRestoreView11Compatibility</param-name>
<param-value>true</param-value>
</context-param>

And solve the problem cause yesterday no one user complain about expired session......
Thanks about memories servers tips......
Do you wanna sugest anything ??

Regards

[Rajneesh Kumar Rajput]

This is good, I'll check up the code base for latest rich faces class may be they have handled the case if view is not found then create a new one like my faces original class do.

But, I see that you have set up the variable value to 200, there are two things,
1) you might not get view expired exception in case if you set that to 200.
2) when I tried with old release i.e. 3.3.0 I found that rich faces does not uses this variable now. Might be they are using this now.

Thanks,

[Rajneesh Kumar Rajput]

Hi All,
I have noticed one more thing is that we have mapped the Faces Servlet in web.xml with /faces/*, so typically it is treating every request is a normal JSF request and causing images, CSS to be cached in the same map which could be the actual cause of this problem in this latest release.

We should change the Faces Servlet mapping to either something /*.jsp. Lets do this change and it must solve our problem permanently.

[Fernando Franzini]

Hi Rajneesh

Did you test that ? so....
This is not a god ideia cause serlvet & jsp specification advises to not override default mapping *.jsp that are using by all servlet container to resolve JSP life cicle . So...I really dont know...

[Rajneesh Kumar Rajput]

Hi Franzini,
Yes, you are right. I actually mean not to use /faces/* as it also treats normal resources like images, css and scripts etc to be processed via JSF request.

So, we will switch mapping to either *.jsf or *.faces, to avoid the problem which is being caused by images, CSS and scripts etc.

I have verified *.faces mapping and now my same pages are working fine even I just have no. of views kept in session to only 4. Lots of gain in memory performance.

[Fernando Franzini]

Hi Rajneesh

This is very strange cause I always use *.faces mapping and I had ViewExpiredException problems ....and it just stop to happing when I increase NUMBER_OF_VIEWS_IN_SESSION to 250 !!!
Only thing that are diferente in my web.xml is extensionsFilter Myfaces that is "/faces/*".
What do you think ?

[Rajneesh Kumar Rajput]

What I have seen so far is in the latest myfaces code base is that, this is a problem pretty much because of any request which is send, is being cached in the viewstate map whether it is script, CSS and images and that is the whole discussion about.

But, it is really strange if you are getting this exception even in case of 200. One more thing, it might be that your browser cache is being expire for the same scripts, images etc or browser is not caching them all and sending requests to the server again and again for the same images etc while rendering the pages.

Please check...

[Fernando Franzini]

Hi Rajneesh

I've checked some clients browsers...and some of them haven't been used cache css, js, images...etc...
So I think this can be the reason of the expire problem....so...I'll configured all my client (15 diferents cities) to use IE and Mozilla page cached...
Thanks and Regards.