Wildfly 10 Memory Leak Issue

Question

I am using wildfly 10.0.0 Final version. I get java.lang.OutOfMemoryError: GC overhead limit exceeded error whenever i undeploy/deploy modules 9-10 times also the memory usage of wildfly keeps on increasing slowly and never decreases and it again gives java.lang.OutOfMemoryError: GC overhead limit exceeded error.

Wildfly is not releasing the memory after undeployment of application and keeps on increasing on deployment and thus it leads to GC overhead

Earlier when i was using wildfly 9 version it didnt gave that problem.

I tried the fix given in the below link by replacing the core, servlet and websocket modules with the latest release but it didnt worked for me.

https://developer.jboss.org/message/959286

Can anyone tell me how to resolve this issue.

Answer 1

You have to increase your heap memory. For this

Edit bin/standalone.conf configuration file, look for the first occurrence of JAVA_OPTS.

Then change the -Xmx option as you need.

If you use Java 8, then

Change:

JAVA_OPTS=”-Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true”

To:

JAVA_OPTS=”-Xms64m -Xmx2G -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=2G -Djava.net.preferIPv4Stack=true”

Resource Link:

WildFly 10 — java.lang.OutOfMemoryError: Metadata space

UPDATE: Classes not unloaded after undeployment

Martin kouba stated below

1. undeploy does not necessarily mean class unloading - it depends on JVM settings (-XX:MaxMetaspaceSize and friends for Java8)
2. I've verified that after 50 deploy/undeploy cycles of the attached reproducer (and using -XX:MaxMetaspaceSize=128m):

for WildFly 10.0.0.Final "java.lang.OutOfMemoryError: Metaspace" occurs

for WildFly 10.1.0-SNAPSHOT (fix for WFLY-6347 merged) no OOM error occurs (metaspace is garbage collected)

After examining the heap dump I've identified the org.jboss.el.cache.BeanPropertiesCache as the root cause. In this case, it keeps a hard reference to the person.joey.test.TestClientBean class, thus effectively blocking the relevant ModuleClassLoader from GC.

Enum values are treated similarly to static constants - i.e. it's not garbage collected unless the class loader of the owner class is.

That's why person.joey.test.RequestType values remain in memory. OmniFaces only amplifies the impact - as mentioned above, it holds a reference to a BeanManager.