Memory problem, BridgeRequestScopeCacheImpl

[Fredrik Jensen，修改在7 年前。]

Hi,
We have memory problems in our portal. We must restart the server a couple of times a week. We took a heap dump in production just before the heap ended. Then we fed it into the Eclipse Memory Analyzer and ran "Find memory leaks".

It turned out that we got a "Problem suspect". See below:

One instance of "org.apache.catalina.core.ApplicationContext" loaded village "org.apache.catalina.loader.StandardClassLoader @ 0x6fe887180" occupies 1,120,023,096 (55.25%) bytes.
The memory is accumulated in one instance of "java.util.concurrent.ConcurrentHashMap $ Node []" loaded by "<System class loader>".

keywords
java.util.concurrent.ConcurrentHashMap $ Node []
org.apache.catalina.core.ApplicationContext
org.apache.catalina.loader.StandardClassLoader

Shortest Paths To the Accumulation Point:

java.util.concurrent.ConcurrentHashMap $ Node [8192] @ 0x75b0c9f30
com.liferay.faces.bridge.scope.internal.BridgeRequestScopeCacheImpl @

After some research, it turns out that some have had similar problems with a leaky BridgeRequestScopeCacheImpl earlier.

So we have a cache of 1.2 GB Faces think that it needs. We guess it's because Faces never take things away from this cache ...

Versions
Liferay 6.2 ce Ga6 (bundled with tomcat 7.0.62),
Liferay Faces 4.2.5-ga6
PrimeFaces 5.3
JSF 2.2
in Faces-config.xml (<default-render-kit-id>PRIMEFACES_MOBILE</default-render-kit-id>)

Liferay runs on windows 2012 server with Java 1.8.0_60

[Neil Griffin，修改在7 年前。]

Hi Fredrik,

The BridgeRequestScopeCacheImpl.java class implements a form of a Least Recently Used (LRU) map. It has a default size of -1 (unlimited / LRU disabled) but can be controlled with the following init-param in portlet.xml:

<init-param>
    <name>javax.portlet.faces.MAX_MANAGED_REQUEST_SCOPES</name>
    <value>1234</value>
</init-param>

The "bridge request scope" (as defined by the JSR 329/378 Spec) is an ActionRequest->ActionRequest type of scope, but in Liferay Faces Bridge that functionality is disabled by default. Instead, the default behavior of Liferay Faces Bridge is ActionRequest->RenderRequest. Do you happen to set the following in your WEB-INF/web.xml descriptor?

<context-param>
	<param-name>com.liferay.faces.bridge.bridgeRequestScopePreserved</param-name>
	<param-value>true</param-value>
</context-param>

If so, that would cause the cache to behave like an ActionRequest->ActionRequest type of scope, which would cause BridgeRequestScopeCacheImpl to keep scope info in the LRU map.

Kind Regards,

Neil

[Fredrik Jensen，修改在7 年前。]

We didn´t set the parameter in WEB-INF / web.xml.

When we did the upgrade to Liferay 6.2, it was a priority to have friendly URLs to work. It worked when we set the following parameters for each postback (navigation) (? Faces-redirect = true). But then we got problems with memory as I described in my first post (BridgeRequestScopeCacheImpl not cleared).

If we try to remove the parameter (? Faces-redirect = true) then friendly URLs doesn´t work. But then the memory management works. Do you have any idea about this behavior.

Maybe there is something about what you wrote about "The bridge request scope (as defined by the JSR 329/378 Spec) is an ActionRequest-> Action Request the type of scope, but in Liferay Faces Bridge That functionality is disabled by default. Instead, , the default behavior of Liferay Faces Bridge ice ActionRequest-> RenderRequest. "

[Neil Griffin，修改在7 年前。]

Hi Fredrik,

Thank you for the details. I think we have enough information to try and reproduce the memory leak. If we need more details then we will let you know.

Kind Regards,

Neil

[Vernon Singleton，修改在7 年前。]

Hi Fredrik,

Fredrik Jensen:

Shortest Paths To the Accumulation Point:

java.util.concurrent.ConcurrentHashMap $ Node [8192] @ 0x75b0c9f30
com.liferay.faces.bridge.scope.internal.BridgeRequestScopeCacheImpl @

I do not have Eclipse Memory Analyzer installed, but I went looking for BridgeRequestScopeLiferayImpl(s) that might be hanging around too long using jvisualvm, and I was able to find that the BridgeRequestScopeCacheImpl was accumulating BridgeRequestScopeLiferayImpl(s) in my session.

The problem went away when I logged out of the application. When I logged out, all of the BridgeRequestScopeLiferayImpl(s) were garbage collected. Do you have lots of folks logged in when you get this accumulation? Like you, I was also testing with the latest liferay-faces-4.2.x. So I then also switched over to the newest released version of Liferay Faces which also has updates for use with Liferay 6.2. I could not reproduce your issue with the latest version of Liferay Faces for 6.2.

So try upgrading to use the recently released liferay-faces-bridge-impl jar. You can visit liferayfaces.org and select Liferay 6.2 and PrimeFaces, and see the dependencies you will want for that combination.

Here are the dependencies I currently get selecting Liferay 6.2, JSF 2.2, and PrimeFaces:

<!-- Liferay Portal 6.2 + JSF 2.2 + PrimeFaces -->
<dependencies>
    <dependency>
        <groupid>commons-fileupload</groupid>
        <artifactid>commons-fileupload</artifactid>
        <version>1.3.1</version>
        <optional>true</optional>
    </dependency>
    <dependency>
        <groupid>commons-io</groupid>
        <artifactid>commons-io</artifactid>
        <version>2.4</version>
        <optional>true</optional>
    </dependency>
    <dependency>
        <groupid>javax.faces</groupid>
        <artifactid>javax.faces-api</artifactid>
        <version>2.2</version>
        <scope>provided</scope>
    </dependency>
    <dependency>
        <groupid>org.glassfish</groupid>
        <artifactid>javax.faces</artifactid>
        <version>2.2.13</version>
        <scope>runtime</scope>
    </dependency>
    <dependency>
        <groupid>com.liferay.faces</groupid>
        <artifactid>com.liferay.faces.bridge.ext</artifactid>
        <version>3.0.0</version>
    </dependency>
    <dependency>
        <groupid>com.liferay.faces</groupid>
        <artifactid>com.liferay.faces.bridge.impl</artifactid>
        <version>4.0.0</version>
    </dependency>
    <dependency>
        <groupid>log4j</groupid>
        <artifactid>log4j</artifactid>
        <version>1.2.14</version>
    </dependency>
    <dependency>
        <groupid>org.primefaces</groupid>
        <artifactid>primefaces</artifactid>
        <version>6.0</version>
    </dependency>
</dependencies>

Hope that helps,
Vernon

[Vernon Singleton，修改在7 年前。]

Forgot to mention that part of the updates for Liferay 6.2 in the latest release include a fix for an error in the JSR 329 Spec requirements around managing the bridge request scope - FACES-2665. That fix is most likely why I am not able to reproduce the accumulation you are seeing with the latest liferay-faces-bridge-impl jar.