There were a couple of ThreadLocal variables being held in the BridgeFacesContext and PersistentFacesState class. Instances of these classes were accumulating in the HTTP server threads, as well in the scheduled executor threads performing server push. This has been fixed for 1.7.1. Instance of the View are held by these two objects, giving the impression that the View was leaking, but those by themselves are not.

While not an unbound memory leak, as the number of instances retained would be capped by the number of threads used by the servlet container, that can still be quite a number and an error condition.

There is a new utility class, com.icesoft.util.ThreadLocalUtility that can perform checks to be sure the ThreadLocal variables are null in outbound code paths. It's both verbose, and only really useful once. To check the outbound Servlet threads, it's easiest to create a Filter instance and just call the checkThreadLocals( String location ) method. Any non-null references will be logged in the error category, while non-null confirmations will be logged if the ThreadLocalUtility has Debug log level.

The RunnableRender class has a call to this class protected by a TRACE level logging test in com.icesoft.faces.async.RenderHub. Again, these checks can confirm that the ThreadLocals are null, but are intended more for internal testing during development cycles.

Also, as part of 1.7.1 development we found that there are other paths into the PersistentFacesState's execute() and render() methods (from the dispose+ monitor thread of execution) that have ThreadLocal variables set. There is new code in these methods that checked to see if the PersistentFacesState objects had already been disposed, and if so, threw a FatalRenderingException without clearing the threadLocal instances. These code paths have been fixed in 1.7.1.

see ICE-3073

This issue is not fixed actually. Please take a look at my post here for a way to address this: http://www.icefaces.org/JForum/posts/list/19497.page

You could also flip the fix around and require applications to register method/class signatures that are allowed to have parent's thread local (PersistenFacesState) be copied into the child's thread local map. This way any third party library spanning threads bellow the application code will never be getting references to PersistenFacesState, etc in their own child thread's thread local