Jetty/Howto/Prevent Memory Leaks

Introduction

Well, the most obvious cause of this is memory leaks in your application :) But, if you've thoroughly investigated using tools like jconsole, yourkit, jprofiler or any of the other profiling and analysis tools out there and you can eliminate your code as the source of the problem, read on.

Preventing WebApp Classloader Pinning

There's a class of memory leak problems that are caused by code keeping static references to a webapp classloader. As the webapp is undeployed and redeployed, the static reference lives on, meaning that the webapp classloader cannot be garbage collected, and can eventually lead to permgen exhaustion.

We provide a number of workaround classes that invoke the problematic code with a non-webapp classloader, thereby ensuring a webapp's classloader is not pinned.

How to Configure

Each preventer can be individually enabled by adding an instance to a Server with the addBean(Object) call. Here's an example of how to do it in code:

    Server server = new Server();
    server.addBean(new AppContextLeakPreventer());

The equivalent in code can be added to the $JETTY_HOME/etc/jetty.xml file or any jetty xml file that is configuring a Server instance. Here's the example from code put into in xml:

<Configure id="Server" class="org.eclipse.jetty.server.Server">
 
   <Call name="addBean">
    <Arg>
      <New class="org.eclipse.jetty.util.preventers.AppContextLeakPreventer"/>
    </Arg>
   </Call>
 
</Configure>

As some of these preventers will cause threads to be created, only use the preventer that is relevant to your application.