ViewExpiredException

Question

My ivy application logs many messages like this:

14:02:58.344 ERROR [...Demos.html_dialog] [http-bio-8081-exec-29] [request=/ivy/faces/instances/149AE61A345847D9/EditableTableDemo.xhtml, session=2 (Developer), task=4, application=2147483647, requestId=429, executionContext=SYSTEM, pmv=designer$HtmlDialogDemos$1] 
  Error during rendering of html dialog 'ch.ivyteam.htmldialog.demo.output.EditableTableDemo'
    javax.faces.application.ViewExpiredException: /ch.ivyteam.view.path_info/7/ch.ivyteam.htmldialog.demo.output.EditableTableDemo/EditableTableDemo.xhtmlNo saved view state could be found for the view identifier: /ch.ivyteam.view.path_info/7/ch.ivyteam.htmldialog.demo.output.EditableTableDemo/EditableTableDemo.xhtml
        at org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:181)
        at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:196)
        at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:143)
        at org.apache.myfaces.extensions.validator.core.startup.ExtValLifecycleWrapper.execute(ExtValLifecycleWrapper.java:59)
        at javax.faces.webapp.FacesServlet.service(FacesServlet.java:198)
[--snip--]

What do these messages mean? Why does such an error occur? How can I prevent them?

Accepted Answer

MyFaces only keeps a defined number of views (respectively view states) per session. The log entry indicates, that access to an old view state happened but this view was not saved in memory anymore. This situation may occur, when someone uses a JSF application in multiple browser tabs or when navigating 'back' (on the browser) is used dissipated.

You can adjust this behavior by configuring MyFaces. To do so, consider following.

Number of views in session

Per default, MyFaces keeps the past 20 view states per session. Note, that each request causes generation of a new view. As a result, when navigating through JSF pages, it's basically possible, to navigate 'back' for 20 times. Navigating 'back' further, leads you to views, that don't work anymore since no view state is saved for them. The same happens, when someone is working with with two or more browser tabs/windows. Imagine, someone opens the application first in windowA and then also in a second one (windowB). If now, more than 20 actions are performed (means 20 requests sent) in windowB, it's not possible anymore to perform actions in windowA, since the view state belonging to windowA was already deleted.

This value can be configured with the context-param org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION.

Number of sequential views in session

It does not matter, if an AJaX request or a "normal" http request is sent - each time, a new view is created. But navigating 'back' with the browser, brings you to the past page, before a "normal" request. Any AJaX request is skipped by the browser's back functionality. This leads us to the next issue related to the limitation mentioned above: Imagine, someone is on pageA and then performs a "normal" request (e.g. form-submit) which leads him to pageB. Afterwards, on pageB, the user performs 20 actions which all only create AJaX requests. Now, navigating back by browser only one time is already too much. The state of pageA is not available anymore, it will not work properly.

That's the reason, why there is another context-param org.apache.myfaces.NUMBER_OF_SEQUENTIAL_VIEWS_IN_SESSION. By default it's not set. It allows to keep the number of saved views in a sequence (whereas a sequence can be seen as a series of only AJaX requests), smaller than the total number of saved views. Hence, this may be the key to improve the behavior of a JSF application when multiple browser tabs are used or navigating 'back' is used often.

Note, that a bigger number of saved views causes a bigger memory footprint of a session. This is also the reason why it's limited at all. Configure the params mentioned above relates to the requirements of your application.

The available context-params of MyFaces are documented on https://myfaces.apache.org/core22/myfaces-impl/webconfig.html In the ivy Engine, they can be added to the web.xml in the folder "ServerRoot"/webapps/ivy/WEB-INF/

Answer 2

0

As I have seen, while starting up the ivy engine, no CLIENT_VIEW_STATE_TIMEOUT parameter is registered.

By setting up the web.xml with parameter:

<context-param> <param-name>org.apache.myfaces.CLIENT_VIEW_STATE_TIMEOUT</param-name> <param-value>0</param-value> </context-param>

would that prevent of a ViewExpiredException too?
why it is not registered?

link

answered 19.05.2015 at 15:27

Andreas
(suspended)
accept rate: 0%

edited 21.05.2015 at 15:30

1

Per default the view state is store on server side (javax.faces.STATE_SAVING_METHOD). ivy does so as well.

So it will not matter if you change the CLIENT_VIEW_STATE_TIMEOUT. For sure, you could try to change STATE_SAVING_METHOD to client but it might cause other not yet known problems.

BTW: CLIENT_VIEW_STATE_TIMEOUT already has a default value of '0'. So, there is no need to set it explicitly to '0'.

(20.05.2015 at 09:50) Dominik Regli ♦

ViewExpiredException

Number of views in session

Number of sequential views in session

Follow this question

Related questions