Intermittent java.lang.IndexOutOfBoundsException at javax.faces.component.AttachedObjectListHolder.restoreState

Question

I have a JSF 2.1.21 application with client state saving method. I'm also using PrimeFaces 3.5 + Tomcat 7.0.37.

I use OmniFaces full ajax exception handler to display a custom error page and email me with the stacktrace when a problem happens.

Every day I get at least one email with a java.lang.IndexOutOfBoundsException. It seems to be related with redeployment of the application, but I'm not able to reproduce it.

Here is the stacktrace:

java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
at java.util.ArrayList.rangeCheck(ArrayList.java:604)
at java.util.ArrayList.get(ArrayList.java:382)
at javax.faces.component.AttachedObjectListHolder.restoreState(AttachedObjectListHolder.java:165)
at javax.faces.component.UIComponentBase.restoreState(UIComponentBase.java:1566)
at com.sun.faces.application.view.FaceletPartialStateManagementStrategy$2.visit(FaceletPartialStateManagementStrategy.java:380)
at com.sun.faces.component.visit.FullVisitContext.invokeVisitCallback(FullVisitContext.java:151)
at javax.faces.component.UIComponent.visitTree(UIComponent.java:1612)
at javax.faces.component.UIComponent.visitTree(UIComponent.java:1623)
at javax.faces.component.UIComponent.visitTree(UIComponent.java:1623)
at javax.faces.component.UIComponent.visitTree(UIComponent.java:1623)
at javax.faces.component.UIComponent.visitTree(UIComponent.java:1623)
at javax.faces.component.UIForm.visitTree(UIForm.java:371)
at javax.faces.component.UIComponent.visitTree(UIComponent.java:1623)
at javax.faces.component.UIComponent.visitTree(UIComponent.java:1623)
at com.sun.faces.application.view.FaceletPartialStateManagementStrategy.restoreView(FaceletPartialStateManagementStrategy.java:367)
at com.sun.faces.application.StateManagerImpl.restoreView(StateManagerImpl.java:138)
at com.sun.faces.application.view.ViewHandlingStrategy.restoreView(ViewHandlingStrategy.java:123)
at com.sun.faces.application.view.FaceletViewHandlingStrategy.restoreView(FaceletViewHandlingStrategy.java:569)
at com.sun.faces.application.view.MultiViewHandler.restoreView(MultiViewHandler.java:141)
at javax.faces.application.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:301)
at org.omnifaces.viewhandler.RestorableViewHandler.restoreView(RestorableViewHandler.java:59)
at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:192)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:116)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.primefaces.webapp.filter.FileUploadFilter.doFilter(FileUploadFilter.java:79)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at br.com.spdata.tecnico.filter.MobileFilter.doFilter(MobileFilter.java:53)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:61)
at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
at org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:449)
at org.apache.shiro.web.servlet.AbstractShiroFilter$1.call(AbstractShiroFilter.java:365)
at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90)
at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83)
at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:383)
at org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:362)
at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
at com.googlecode.psiprobe.Tomcat70AgentValve.invoke(Tomcat70AgentValve.java:38)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:936)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1004)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)

Any ideas?

Thanks, Phillip

Gaiter

Please share code also.How can anyone know what your code is? – Laborer

Is this all of the stack trace? No caused by? – Fetch

Related/duplicate: #12094577 It's related to dirty sessions after redeployment. Note OP's own answer at the bottom which specifies a context parameter which should fix this. Give it a try. It may or may not fix your particular problem. – Zanezaneski

@subodh I didn't add any code because this problem happens in different pages, with different managed bean scopes. – Gaiter

@Fetch I'm using Apache Commons Lang ExceptionUtils.getStackStrace(), but it seems it's not returning the full stack strace. I've changed the code to log this exception, so I when it happens again I can attach a new stacktrace and some code. – Gaiter

@Zanezaneski thanks for the link, but I have only a single Tomcat instance. I'm using the default session persistence mechanism, but I don't restart the server on redeploy. I use parallel deploy, so only new sessions should go to the new version of the application. I'll try setting PARTIAL_STATE_SAVING to false, do you know if it will be more memory/cpu extensive? – Gaiter

Same error here on an f:ajax request on some specific pages. Setting javax.faces.PARTIAL_STATE_SAVING to false resolved it. – Nimocks

Answer 1

StackOverflow eventually reminds me of this question existence, so I'll take some minutes to answer how I solved it.

I guess it's not possible to replace a running JSF webapp without view state related exceptions if the page structure that the user was accessing changed somehow.

I was able to perfectly solve this using Tomcat's parallel deployment, where older versions of the webapp stay on the server until they have active sessions.

Gaiter

the corret answer specified in #12094577 – Repletion

There is no "correct" answer in this case, but different approaches to handle the situation... – Gaiter

Hehehe u r vaild here okay let me be specific "The link is the solution that worked for perfectly for the exact same exception". – Repletion