Need to repeat load test.

Using ICEfaces3 trunk I re-ran the load test using 2, 4 and 8 windows. I didn't see the exceptions mentioned here but did encounter the following exception a number of times:
Sep 25, 2012 7:14:55 PM org.icefaces.impl.event.BridgeSetup getBodyResources
WARNING: Unable to find WindowScope for view /auction.xhtml
java.lang.NullPointerException
at org.icefaces.impl.event.WindowAndViewIDSetup$1.encode(WindowAndViewIDSetup.java:65)
at org.icefaces.impl.event.UIOutputWriter.encodeBegin(UIOutputWriter.java:27)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1777)
at javax.faces.render.Renderer.encodeChildren(Renderer.java:168)
at org.icefaces.impl.renderkit.RendererWrapper.encodeChildren(RendererWrapper.java:49)
at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:845)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1779)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1782)
at org.icefaces.impl.context.DOMPartialViewContext.processPartial(DOMPartialViewContext.java:142)
at javax.faces.component.UIViewRoot.encodeChildren(UIViewRoot.java:981)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1779)
at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:409)
at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:124)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:121)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:594)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:225)
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:168)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
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:1001)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:585)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)

I unlinked this case from ICE-8511 because of the following.
I believe the usage of the load.sh test as described in this JIRA is a flawed/unfair test. The load.sh uses a fixed location for the cookie bin. When starting the test in an x number of console windows, this cookie bin will be used by all the used console windows. This results in using the same Window ID for all console windows, which seems unfair to me. In the case of using 4 console windows, you would now have 4 console windows hammering the server with a 1000 requests each all using the same Window ID.
The auction application doesn't have any window scoped beans in it. This results in the WindowScope to be constantly activated and deactivated. During this test it could happen that at some point the WindowScope is deactivated while it's trying to retrieve it resulting in the mentioned NullPointerException.
At this point it's unclear if this is the same situation as ICE-8511, though it looks similar.
(Restricted to faces-core group)

This doesn't seem any different from a rare startup case with two windows, potentially leading to the same race condition with WindowScope create/destroy.

ICEpush has been considerably refactored, invalidating these Exceptions. The result is that it is simply necessary to conduct a load test.