It looks like Mojarra 2.1.3 has a similar behaviour where the component tree grows continually with each AJAX postpack due to re-arranging of the resources done by MandatoryResourceSetup and ResourceOrdering system event listeners.

The fix that works both for 2.1.3 and >2.1.10 is to mark the parents of re-ordered components as not in view, avoiding thus the firing of component addition or removal. The result is that JSF state saving will not react (by trying to restore component addition or removal) to the modifications done by our system event listeners.

Re-opening the case. As reported in ICE-8717, yesterday's changes related to this case (r31825 and r31833) are now causing the following exception when running the component-showcase example:
java.lang.NullPointerException
at com.sun.faces.application.view.StateManagementStrategyImpl$4.visit(StateManagementStrategyImpl.java:331)
at com.sun.faces.component.visit.FullVisitContext.invokeVisitCallback(FullVisitContext.java:151)
at javax.faces.component.UIComponent.visitTree(UIComponent.java:1590)
at javax.faces.component.UIComponent.visitTree(UIComponent.java:1601)
at com.sun.faces.application.view.StateManagementStrategyImpl.restoreView(StateManagementStrategyImpl.java:326)
at com.sun.faces.application.StateManagerImpl.restoreView(StateManagerImpl.java:188)
at com.sun.faces.application.view.ViewHandlingStrategy.restoreView(ViewHandlingStrategy.java:123)
at com.sun.faces.application.view.FaceletViewHandlingStrategy.restoreView(FaceletViewHandlingStrategy.java:453)
at com.sun.faces.application.view.MultiViewHandler.restoreView(MultiViewHandler.java:148)
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.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:312)
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:680)
I verified these changes as the cause by reverting them and re-running the component-showcase example.

There doesn't seem to be a problem with showcase app, either in the ACE or ICE sections. Using the debugger, I can see that the code that is throwing the NPE is never hit when running the current showcase - only when running component-showcase:

                Object restoredAddList[] = (Object[]) state.get(CLIENTIDS_TO_ADD_NAME);
                if (restoredAddList != null && restoredAddList.length > 0) {
                    // Restore the list of added components
                    List<ComponentStruct> addList = new ArrayList<ComponentStruct>
...
(restoredAddList.length);

As it's trying to restore the list of added components, it looks like the one or more of the state entries is "corrupted" or at least in a format that the code doesn't like.

I've tested the scenarios described in the description with latest icefaces3/trunk, rvn#30887 and see no issues with the compat/component-showcase ice:dataTable demo.

However, using the showcase demo w/ Tomcat and FF I do see fairly slow performance when using the row selector demo. Also, clicking through many subsequent selections does result in continually increasing response times.

This needs priority evaluation.