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.
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.