OOM Metaspace while redeploying WAR application in WildFly

[luStopai]

Hi

I think there's some problem with class unloading when deploying a spring boot application as war on a web server such as wildfly.

I had this issue where after some deployments I got OOM Metaspace error. In order to discard some bug in my code causing this problem I created a new spring boot project with https://start.spring.io/ and deployed it a few times getting an OOM Metaspace error again. So my guess is that there's something in springboot itself causing the problem.

Steps to reproduce:

1. Go to https://start.spring.io/
2. Change packaging from jar to war
3. Add spring web dependency (not sure if it's a necessary step)
4. Download wildfly
5. Open the project and build the war file
6. Deploy it to wildfly
7. Redeploying the project will increase the amount of classes loaded, and the metaspace used until there's no free space left getting the OOM Metaspace error

Tip: If you run wildfly with -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m you'll reach OOM Metaspace error with about 10 redeployments. If you are wondering where did I get these numbers, I think this is the default configuration of https://hub.docker.com/r/jboss/wildfly/

I attached a screenshot of visualVM monitoring the redeployments where you can clearly see how metaspace increases after each redeploy

FYI: I don't know much about class loading/unloading, metaspace issues, etc. but this is the conclusion I reached after some research. If this is not the right place to report this issue feel free to close it. Anyway any help or orientation will be much appreciated

Thanks

[bclozel]

Hello @luStopai , thanks for raising this issue.
I might have found something we can improve here, I'd like to get your feedback on that.

First, here's how I worked on this:

1. downloaded WildFly 18.0.1 full
2. created a Spring Boot application on start.spring.io with the web starter and the WAR packaging
3. Opened Yourkit and instrumented the standalone.sh script using the wizard
4. started wildfly and opened the profiling view for it in Yourkit
5. packaged the and deployed it several times in a row using the browser console

While redeploying the application, I'm seeing indeed the number of classes being loaded increasing. Manual GCs do not improve the situation.

After taking a memory snapshot and going in the "Class loader" section, I'm indeed seeing Spring classes being loaded but with zero instances of those classes. They're loaded by an org.jboss.modules.ModuleClassLoader. Looking at the "paths from GC roots", I'm seeing a few from container of org.jboss.msc.service.ServiceContainerImpl$ServiceThread, but also some from application context shutdown hook.

Could you please amend your ServletInitializer in your application?

package com.example.demo;
import org.springframework.boot.builder.SpringApplicationBuilder;
import org.springframework.boot.web.servlet.support.SpringBootServletInitializer;

public class ServletInitializer extends SpringBootServletInitializer {

  @Override
  protected SpringApplicationBuilder configure(SpringApplicationBuilder application) {
    return application.registerShutdownHook(false).sources(DemoApplication.class);
  }
}

I've tested that and I'm seeing significant improvement. The number of classes can remain high but triggering GCs manually with Yourkit clears a lot.

[luStopai]

Hi bclozel,

Thanks for your feedback. I just did a much deeper testing with very interesting results. The firsts tests didn't change with and without registerShutdownHook(false), but since I started to find out some new things I did the rest of the testing without registerShutdownHook(false).

I tested different scenarios:

1. Running wildfly as regular user:
   a) If I run wildfly as regular user (executing ./standalone.sh) and deploy and redeploy the war file from the web console, then triggering GC manually does unload thousands of objects and frees metaspace. Also if I don't trigger GC manually, it triggers automatically before getting OOM.
   b) If I run wildfly locally as regular user from Intellij and deploy and redeploy the war file from Intellij, then triggering GC manually frees heap memory but no metaspace memory. Also metaspace increases until I get OOM, after which GC triggers and frees all metaspace that got accumulated from previous deployments. The deployment in which this happens doesn't really deploy, in fact since it undeploys fine does not deploy, the result is that when getting OOM there's no app deployed. But if after that I deploy the app again, everything works just fine.
   Note: I noticed that maybe this issue is related to the fact that intellij deploys the app to local wildfly as unmanaged deployment.

2. Running wildfly as a system service:
   If I run wildfly as a system service then I cannot trigger GC manually. But it automatically frees metaspace automatically before reaching OOM, both deploying manually or using intellij.
   Note: In this case I deployed with intellij to wildfly as a remote wildfly which deploys as a managed deployment (the same way as manual deployment).

3. Running wildfly using docker:
   If I run wildfly using docker, which runs as a regular user inside the docker container (I think), then triggering GC manually frees heap memory but no metaspace memory. But it automatically frees metaspace automatically before reaching OOM, both deploying manually or using intellij.

At this point I am quite confused since I used to have this issue when deploying manually to a wildfly running as a system service.

Some scenarios prove that metaspace can be freed with no problem, so now it doesn't seem to be a spring related issue. Altough, I don't understand why some scenarios free metaspace memory only after getting OOM.

Anyway, I think I need to do some more research and tests, and that is save to say that this issue can be closed, because now it doesn't seem spring related.

What do you think? and also, what does registerShutdownHook(false) do?

[bclozel]

Looking at the metaspace size on its own might mix a lot of problems together. There have been several OOM-metaspace related issues in the wildfly issue tracker - so your experience might vary depending on the version and the setup. Knowing which classes/classloaders are cluttering the metaspace is important.

In the meantime, I've tested again and my previous improvement was a false positive. The shutdown hook was indeed the shortest GC path, but triggering more manual GCs did decrease the classes count to the expected level. In short, I can't reproduce the issue on a Wildfly standalone setup.

registerShutdownHook registers... a shutdown hook into the JVM to close the application context when the JVM is shut down. This is really useful for command-line or embedded server applications, but in the case of a deployed WAR in a Servlet container we should not register that and we should instead let the container manage the application lifecycle. We'll probably apply that change anyway. I've created #19398.

I'm closing this issue now.