0005914: JSP tag classes leaking

Viewing Issue Simple Details [ Jump to Notes ]

[ View Advanced ] [ Issue History ] [ Print ]

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[^]

27 total queries executed.
25 unique queries executed.