Reducing NUMBER_OF_VIEWS_IN_SESSION results in ViewExpiredException

Question

I'm running myFaces 2.1.7 and desperatly trying to reduche the mmeory usage of our web application. Basically session size of each users ballons to up to 10MB which we can't handle.

I tried adding the following to Descriptor:

        <context-param>
            <param-name>org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION</param-name>
            <param-value>3</param-value>
        </context-param>

result was ok and the session size of any given user wasn't going higher than 1MB. But then alot of users aren't able to login since the change. What is happening is that on login screen ViewExpiredException is thrown , and i wrote a custom viewExpiredException class that redirects the user back to login screen, so essentially they're stuck on login screen loop

 try to log in ---> ViewExpiredException thrown --->  Custom ViewExpiredHandler ----> Forward user to Login Screen
 <----------------------------------------------------------------------------------------------------------------

Removing the above context-param fixes the issue! My question is one -

  1) why is the viewException is thrown when the NUMBER_OF_VIEWS_IN_SESSION is reduced from its default value 
  2) is it possible to work around the issue by using the custom ViewExpiredHandler class ? how?
  3) am i doing something wrong in causing this issue?

P.S. in testing why this is happening, if i open for example IE and try to login all is ok, but then if i try to open another browser (e.g. chrome) and login using another username above issues are encountered mirroring issues reported by users not being able to login.

Also following hints of myFaces wiki i have added the following to descriptor but i don't believe it can contribute to the issue:

<context-param>
    <param-name>org.apache.myfaces.SERIALIZE_STATE_IN_SESSION</param-name>
    <param-value>false</param-value>
</context-param>

Update:

As suggested by BalusC i change the STATE_SAVING_METHOD to client in order to resolve the memory issues we are having . immediately all UAT testers reported dramatic slow down on all page load speeds so i had to revert back to having STATE_SAVING_METHOD set to server.

Since I've been experimenting with value of org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION and with the current value of 6 (an improvement of 70% over the default 20 sessions) i am not getting the ViewExpiredException errors any more.(reason why this question was created originally)

But in a way i am playing russian roulette. I don't really know why having the value of org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION set to 3/4/5 didn't work and why 6 is working and it bothers me not being able to explain it. Is anyone able to provide information?

If memory is so expensive for you, why not just setting state saving method to client? Never a `ViewExpiredException` anymore. — BalusC, May 08 '12 at 02:40
@BalusC i inherited the application and it was setup this way (server side state saving)- Memory is expensive in a sense that there are other web-servers running on same machine so the total of 8GB ram is shared amongst this tomcat and others. This tomcat i am working on is restricted to 1GB heap space. I also read in performance tuning of myFaces wiki where said `its recommended to have State Saving method as SERVER` but can't find any detail on what actual difference it makes in real life having it set to Client method. Is setting the State Save method to client the only possible solution? — ke3pup, May 08 '12 at 03:37

score 1 · Accepted Answer · answered Jun 10 '12 at 17:16

I originally asked this question after noticing how the use of browser's BACK button was causing ViewExpired Exception to be thrown.

I had also reduced the default value of 20 for org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION to 3 and then 6 (in trying memory foot print) which aggravated the problem.

Having wrote a ViewExpired Exception Handler, i was now looking for a way to do something about the Exception when it was thrown and below is how i am dealing with it:

    1 - `org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION ` value is 6

    2 - when ViewExpired Exception is thrown in ViewExpired Handler retrieve the request URL
            HttpServletRequest orgRequest = (HttpServletRequest) fc.getExternalContext().getRequest();

    3 - insert a boolean into user session (used as flag to be used below)
                Map<String, Object> sessionMap = FacesContext.getCurrentInstance()
                        .getExternalContext().getSessionMap();
                sessionMap.put("refreshedMaxSesion",true);

    4 - redirect back to URL retrieved in step 2
                   fc.getExternalContext().redirect(orgRequest.getRequestURI());

    5 - Since page is reloaded , see if the flag in step 3 exists and if so flag a notification to be shown to user and remove from session
                 if(sessionMap.containsKey("refreshedMaxSesion")){
            showPageForceRefreshed = true;
            sessionMap.remove("refreshedMaxSesion");
        }

    6 - I'm using Pines Notify to show subtle "FYI, this page way refreshed" type message".
           <h:outputText rendered="#{ myBean.showPageForceRefreshed }" id="PageWasRefreshedInfoId" >
                <script type="text/javascript">
                    newjq(document).ready(function(){
                        newjq.pnotify({
                            pnotify_title: 'Info',
                            pnotify_text: 'Ehem, Page was Refreshed.' ,
                            pnotify_mouse_reset: false,
                            pnotify_type: 'info',
                            pnotify_delay: 5000
                        });
                    });
                </script>
            </h:outputText>

Another notification option would be to add a FacesMessage to the faces context before the redirect, in case your project is not using Pines. This way you can skip over steps 3, 5, and 6. — Ali Cheaito, Jul 17 '13 at 13:50

Reducing NUMBER_OF_VIEWS_IN_SESSION results in ViewExpiredException

Update:

1 Answers1