使用嵌入式Jetty作为应用程序服务器时内存被阻止

Question

I am using embedded jetty as a Java application server, with maximum JVM memory set to 800MB. I created a method to deploy and un-deploy web archives. Every time I deploy a war with a basic hello world application the embedded application server uses approximately 200MB additional memory which causes an out of memory after I add the 4th web app. Is this the expected behaviour for embedded Jetty when used as an application server?

@ManagedOperation
public boolean deployWebApp(String context, String pathToWar){
    boolean success = false;
    WebAppContext webctx = null;
    try{
        webctx = addWebApp(context, pathToWar);
        webctx.getTempDirectory();
        webctx.start();
        success = webctx.isRunning();
    } catch (Exception e) {
        e.printStackTrace();
        logger.log(Level.SEVERE, "Failed to startup webapp with webappcontext: ", webapps.get(context).getContextPath());           
    }
    return success;     
}

Answer 1

No, I use embedded Jetty and it doesn't use anything like that amount of memory.

The best thing to do is create a heap dump and then use a tool like the Eclipse Memory Analyzer to analyse the heap and see what it is about the web apps that are consuming so much memory.

Answer 2

The undeploy/deploy memory leak could be related to various known JRE ClassLoader pinning issues.

We've recently (as of the past 2 days!) added some pre-emptive preventers of this pinning to the server side classloader to allow the WebAppClassLoader to operate in a way that doesn't leak references to the ClassLoader.

See: http://git.eclipse.org/c/jetty/org.eclipse.jetty.project.git/tree/jetty-util/src/main/java/org/eclipse/jetty/util/preventers

These are all added to the server via the Server.addBean(Object) method.

You might have some luck using these on your embedded server.

Answer 3

After playing around with jconsole and going through each of the handlers in the contexthandlercollection, it was discovered the undeployed webapps were not deleting the securityhandlers and sessionhandlers, as result the perm gen kept growing.

We programmatically deleted each of those handlers and we can see the perm gen memory reducing.

this.getSessionHandler().stop();
this.getSessionHandler().destroy();
this.getSecurityHandler().stop();
this.getSecurityHandler().destroy();