myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rajneesh K Rajput <rajne...@contata.com>
Subject Re: ViewExpiredException: (Myfaces1.2.6 and Richfaces3.3.0) Possible problem and solution discussion.
Date Fri, 10 Jul 2009 12:59:32 GMT

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. 

Finally, my problem is solved. 


Rajneesh K Rajput wrote:
> 
> 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. 
> 
> 
> 
> Rajneesh K Rajput wrote:
>> 
>> There are lots of details given for the rich faces but they are just to
>> explain the problem that we are facing, but want to discuss something
>> related to my faces latest implementation.
>> 
>> <p> Actual Problem </p>
>> 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.
>> 
>> <p> Discussion point in My faces  </p>
>> 
>> Anyways, what I found is related to Rich Faces class how it is storing
>> the view state map, but want to confirm here also why MyFaces new
>> implementation for the class RestoreViewExecutor throws an exception if
>> no view is found in post back request, while older version of this class
>> was creating a new instance of view state if not found. 
>> 
>> <p> ------------------------------------------------------ </p>
>> Details for Rich Faces related work, not required here in my faces forum
>> but will help to understand the problem that we are facing now. 
>> 
>> <p></p>
>> Please see what we found in this.
>> <p></p>
>> Initial configurations were as follows..
>> javax.faces.STATE_SAVING_METHOD=server
>> org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION = 4
>> <p></p>
>> 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.
>> <p></p>
>> I debug the code and found couple of facts,
>> <p></p>
>> 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.
>> <p></p>
>> 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.
>> <p></p>
>> 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.
>> <p></p>
>> 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.
>> <p></p>
>> <u>Proposed Solution 1:</u>
>> <p></p>
>> 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.
>> <p></p>
>> 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 AjaxStateHolder view state map ? .
>> <p></p>
>> If it is really not required to store images, css and scripts in the same
>> view state map, this will solve our problem completely.
>> <p></p>
>> 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.
>> <p></p>
>> 
>> <u>Proposed Solution 2 [Temporarily]:</u> 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.
>> 
>> 
> 
> 

-- 
View this message in context: http://www.nabble.com/ViewExpiredException%3A-%28Myfaces1.2.6-and-Richfaces3.3.0%29-Possible-problem-and-solution-discussion.-tp24203426p24427110.html
Sent from the MyFaces - Users mailing list archive at Nabble.com.


Mime
View raw message