Mantis - Resin
Viewing Issue Advanced Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
4684 crash always 07-26-11 02:06 07-26-11 09:11
Reporter: paru Platform:  
Assigned To: ferg OS:  
Priority: normal OS Version:  
Status: closed Product Version: 4.0.20  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
Summary: 0004684: Another JPA classloader leak
Description: There's another resin classloader leak which prevents a web application's classloader can be garbage collected which will sooner or later result in an OutOfMemoryError.

The cause of the issue is that resin loads the JPA implementation library included
within a web application (e.g. EclipseLink) with the global classloader instead of the
web application's classloader. (why?)
As a result, even after the stopping of a web application these classes remain loaded and stay in memory.

What makes this even worse is that if a JPA implementation class
refers to a class of my web application which is quite common (if you think of hooks,
configuration classes etc.) the web application
classloader also remains referenced and prevents its garbage collection forever.
Steps To Reproduce:
Additional Information: Although I did not test it I think that this bug might also cause strange classloading issues when using different releases of the same JPA provider within the same resin server.
Relationships
Attached Files:

Notes
(0005403)
ferg   
07-26-11 09:11   
As reported, this is not a bug.

Libraries are perfectly capable of being written to be class-loader safe. The techniques are straightforward and well-known, and including handling callbacks and configuration.

Part of the design of the JPA API is to allow classloader-safe implementation.

If eclipselink has a classloader bug, that is an eclipselink bug, and should be reported as such.

However, this bug report is based on nothing but guesses about eclipselink's implementation, and an apparent confusion of how libraries and classloaders work.