| Anonymous | Login | Signup for a new account | 02-22-2026 15:14 PST |
| Main | My View | View Issues | Change Log | Docs |
| Viewing Issue Simple Details [ Jump to Notes ] | [ View Advanced ] [ Issue History ] [ Print ] | ||||||||
| ID | Category | Severity | Reproducibility | Date Submitted | Last Update | ||||
| 0004684 | [Resin] | crash | always | 07-26-11 02:06 | 07-26-11 09:11 | ||||
| Reporter | paru | View Status | public | ||||||
| Assigned To | ferg | ||||||||
| Priority | normal | Resolution | open | ||||||
| Status | closed | Product Version | 4.0.20 | ||||||
| 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. |
||||||||
| 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. | ||||||||
| Attached Files | |||||||||
|
|
|||||||||
| Mantis 1.0.0rc3[^]
Copyright © 2000 - 2005 Mantis Group
30 total queries executed. 26 unique queries executed. |