QA has reported that a server with 3 instances of component-showcase runs out of heap space (with 64M configured) with 3 clients running with state saving turned on. This doesn't happen with state saving turned off.

There are a couple of implementation details that can account for this.

One, JSF stores state in a two stage map structure with one Map (referred to as the actualMap in JSF source) containing the tree structure and state for a View, one entry per render, default capacity of 15. This is used in JSF's support of the back/forward key with 15 steps allowed before any given capture is released from the map. The other map (the logicalMap) holds the actual Maps for all of the Views supported for a client.

ICEfaces doesn't really need either of these concepts. ICEfaces doesn't support the back button so essentially all the the duplicate copies in the actual map are wastage. Also the notion of having a Map that holds all the actual Maps for a view is also wastage and an unnecessary limitation on the number of views available to ICEfaces. On a page reload, a fresh entry is created in this outer logical map despite the viewId still being the same.

Theoretically, it's easy to create a new StateManager implementation that better reflects the needs of ICEfaces. In practice, the StateManager is one of the underlying-technology-aware components available from the RenderKit API. We could:

- Copy the StateManagerImpl code and create our own RenderKit implementations for ResponseStateManager, RequestStateManager, etc., and fully flesh out the RenderKit API. This is the 'right' thing to do, but has some time and testing risks.

- Copy the StateManagerImpl code and replace any use of the RenderKit API. I think our implementation of the DOMResponseWriter is something like this, since it's supposed to be another technology aware part of the RenderKit idea. We can probably do this, with more work to be redone later.

- We can't use the JSF implementations since they're in the RI, and including them in the compilation unit would break Myfaces, and would require rejigging the build environment.

- Just turn it off. Use the existing state preservation in ICEfaces.

- Clients who have special restrictions can minimize the impact of the JSF implementation using configuration parameters. You can dial down the number of logical maps if your application supports a restricted number of physical Views. Also, you can configure down the size of the ActualMap to 2 or 3. The client should be aware of a race condition if the size of the actualMap is set to 1. In this case, it's easy to have server push generate a new render (with subsequent entry in the state map) with UI coming from the client referring to the map entry that had generated the view. The key coming from the client will then correspond to no entry in the actual map, and a ViewExpired exception will be thrown. This minimizes the impact of the memory consumption.

The other part of the problem is the inefficiency in the state saving itself. We create Object[] to accomodate the largest number of Effects, when most of the values are null. The API doesn't specify what the components are to put in the Object[], so it's possible to easily create a Map containing Effects objects only if they exist, keyed by a simple string identifying which is which. The amount of memory savings in this case is still to be determined.