Mantis Bugtracker
  

Viewing Issue Simple Details Jump to Notes ] View Advanced ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0005914 [Resin] major always 06-02-15 15:33 06-09-15 14:20
Reporter nfedorov View Status public  
Assigned To ferg
Priority normal Resolution fixed  
Status closed   Product Version 4.0.43
Summary 0005914: JSP tag classes leaking
Description Resin creates a new class loader anytime a JSP class needs to be loaded. If a JSP page happens to use JSP tags (defined in *.tag files), the class of each tag is loaded using the same class loader, along with the main JSP class.

If there are 100 JSP pages using the same JSP tag, the class of the tag will be loaded 100 times, once with each JSP page, creating 100 tag class duplicates.

The problem affects only JSP tags (*.tag files), not Java tags defined in *.tld files.

Not only this seems to be a performance problem since the same JSP tag classes are loaded and defined over and over, it also creates a memory leak since many class duplicates coexist in PermGen eating up the space.

Further, anytime a JSP class is cached in memory, its class loader cannot be unloaded and all of the JSP tag classes loaded by that class loader stay in memory too.

For example, the ReflectionAnnotationFactory holds a WeakHashMap of introspected types. Every JSP class is introspected and cached in that map. The values are softly referenced and so the JSP classes are kept in memory for a while, along with their respective class loaders and all of the JSP tag class duplicates loaded with that JSP.

===

The application we run on resin heavily relies on JSP tags and we can see thousands of JSP tag class duplicates in memory dumps (70-80% of total amount of loaded classes in some cases).

At some point, GC seems to start unloading softly referenced JSP classes along with the JSP tag classes at a higher rate to avoid OutOfMemoryError in PermGen region, but then these JSPs are loaded back upon the next use.

Loading/unloading of JSP classes at high rate degrades the performance of the application. Thread dumps show ClassLoader.defineClass on top of stacktraces of many threads when this happens.

Increasing the size of PermGen region alleviates the problem, but does not solve it as the class duplicates are still kept in memory.

===

To reproduce, define a simple JSP tag, use it in two JSP pages, deploy the webapp and visit both JSP pages, inspect the content of memory for class duplicates, notice the dangling class loaders and classes they loaded.
Additional Information
Attached Files

- Relationships

There are no notes attached to this issue.

- Issue History
Date Modified Username Field Change
06-02-15 15:33 nfedorov New Issue
06-09-15 14:20 ferg Assigned To  => ferg
06-09-15 14:20 ferg Status new => closed
06-09-15 14:20 ferg Resolution open => fixed
06-09-15 14:20 ferg Fixed in Version  => 4.0.45


Mantis 1.0.0rc3[^]
Copyright © 2000 - 2005 Mantis Group
27 total queries executed.
25 unique queries executed.
Powered by Mantis Bugtracker