Steps to reproduce 1. Start JPP 2. Deploy JSF2 jsf2portlet (or any other portlet using Session, View or Request Scoped beans) to JPP 3. Add portlet to some page 4. Go to that page 5. Run VisualVM and connect to JPP process, go to Head Dump, target bean should be visible there 6. Wait for session expiration 7. Perform Garbage collection 8. Bean still hangs in memory Useful links Same issue reported in Liferay - http://issues.liferay.com/browse/FACES-1470 Related issue with @PreDestroy lifecycle event - https://issues.jboss.org/browse/JBPAPP-10496 I am also adding comment from Ken Finnigan Basically it's a problem of EAP creating its own listener hooks for the JSF lifecycle, which means that JSF doesn't have a handle to the objects to correctly clean them up, so they linger in memory. The issue was originally discovered in JSF 2.1.16, and fixes are in 2.1.18 to resolve the JSF side but alterations to PBR are also needed to make it work. To my knowledge, it hasn't been verified to be a problem prior to 2.1.16, as it was raised with that version and view scoped beans. Thomas is correct that that version of JSF is only expected in EAP 6.1 and higher.
EAP 6.1 has been upgraded to JSF 2.1.19. So the JSF side of the issue should be fixed.
If JPP 6.1 is based on EAP 6.1, then no JSF update is required (as per Stan's previous comment). However, if JPP 6.1 will continue to be based off EAP 6.0.1, then we will also need to include the patch for EAP to upgrade JSF to 2.1.19
I've tried to test this leak in JPP 6.1.ER01 and the issue still persists. I didn't modify WAR file of the jsf2-hello-world-portlet in any way except adding the session timeout.
Memory leak issue seems to be gone in ER02, beans are correctly garbage collected after session timeout.
Hi Ken Just made the required changes to the RN for this issue to upgrade it to a Bug Fix from a Known Issue. Cheers Jared
According to Comment#34 in BZ#991844 by Dominik, this issue does not require a release note. Zeroing out the Release Note fields and flags.