Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>This is class loader memory leak. Each time you redeploy the application, a new classloader is created for it and all classes of your application are loaded again. This consumes memory in the perm gen space.</p> <p>The old classloader and all its loaded classes have to be garbage collected, otherwise you will eventually run into a PermGen space OOME after deploying multiple times. This does not work if an object loaded by an outside classloader holds a reference to any object loaded by the old classloader. <a href="http://blogs.oracle.com/fkieviet/entry/classloader_leaks_the_dreaded_java" rel="noreferrer">This article</a> gives a good explanation of the problem.</p> <p>Generally, classloader leaks are difficult to analyze and sometimes difficult to fix. To find out why the old classloaders are not garbage collected, you have to use a profiler. In <a href="http://www.ej-technologies.com/products/jprofiler/overview.html" rel="noreferrer">JProfiler</a>, use the heap walker, select the glassfish classloader objects and use the incoming references view to check for paths to garbage collector roots.</p> <p>The class loader class is called <code>org.apache.servlet.jasper.JasperLoader</code>. Here's a screenshot of a regular situation, where the class loader is only held by live instances of loaded objects.</p> <p><img src="https://i.stack.imgur.com/B6u2Q.png" alt="enter image description here"></p> <p>In your situation, you should see references from outside objects. Another common cause of a classloader leak in web containers is a background thread that is not stopped. Google Guice for example has such a bug in 3.0.</p> <p>(Disclaimer: my company develops JProfiler)</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload