AutoUpdate: Memory Leak

HISTORY

We recently updated an application from PF 6.1 to 6.2.20. Our application won’t stay alive for more the 24 hours without going into a GC death spiral and running out of memory.

We have narrowed the leak down to leaking copies of javax.faces.component.StateHolderSaver

1) Environment

• PrimeFaces version: 6.2.20
• Does it work on the newest released PrimeFaces version? NO on 7.0.3
• Does it work on the newest sources in GitHub? NO on 7.1.1-SNAPSHOT
• Application server + version: Mojarra 2.2/2.3, Jboss EAP 7.1
• Affected browsers: ALL

2) Steps to reproduce

Attached is a sample runner: pf-memleak.zip

Run the application and navigate to http://localhost:8080/primefaces-test/test.xhtml and just leave the page running.

Run JVisualVM and just monitor javax.faces.component.StateHolderSaver you will see the instances climb. If you press “Perform GC” you will see the instances go down but then come back extremely fast as they all get re-instantiated. It will also garbage collect but start at a higher number each time like instances are being held onto to. After 24 hours and 1000’s of users we eventually run out of all resources.

If you open 2 or 3 different browsers on your machine you will see the problem happen even faster and more aggressively.

5) Sample XHTML

	<h:form id="frmTest">
		<p:messages id="globalMessages">
			<p:autoUpdate />
		</p:messages>
		<p:poll id="pllTest" interval="1" listener="#{basicController.controllerMethod()}" update="txtTest " />
		<h:outputText id="txtTest" value="#{basicForm.value}" />
	</h:form>

6) Visual VM

7) Analysis

• If you use Mojarra 2.2. or 2.3 we see the leak. Using MyFaces 2.2 and 2.3 it doesn’t appear to happen but it looks like MyFaces uses different classes.
• If we remove the <p:autoUpdate> and have the poller just do update=“” our app no longer leaks these javax.faces.component.StateHolderSaver.
• If you do “Perform GC” over and over you will see each time the StateHolderSaver garbage collect but each time they garbage collect but start at a higher number each time. Because we have say 1000-2000 users all on this page all day you can see how it can leak and not survive for more than 24 hours.

[tandraschko]

the listener will be replaced only with jetty:run-exploded, therefore jetty:run won’t work out of the box

[cnsgithub]

I just removed this from web.xml:

    <listener>
        <listener-class>${jsf-listener}</listener-class>
    </listener>

Then jetty:run is working with YJP profiling from within IntelliJ.