Memory leak when building session factory from xml, classloader does not get garbage-collected

Description

Hello.

I was able to create a minimum web-application which fails to be garbage collected if session factory uses xml configuration file. This does not happens when it is created programmatically.

The big issue is that in production environment this problem leads to a OutOfMemoryException because of PermGen (because it is needed to restart the context from time to time)

When building session factory from xml, and after starting and then stopping context, I can see all the classes from the webapp using any profiler (jvisualvm, eclipse's memory analyzer, etc). But I could not figure out if the problem is due to how hibernate uses Dom4J or if it is a Dom4J problem. I also switched to many different version of Dom4J but problem still remains.

Here I provide a minimal web application which has only 1 (one) class that creates an empty session factory (this class is a ServletContextListener and is named FDVContextListener) with only a database connection. No mappings at all. The experiment consists in start a Tomcat (maybe 6.0.25+ or 7.x which has the memory leak feature) and later stop the context. Finally, check for leak you'll find webapps classes still there.

2nd part of the experiment is to modify the listener to make it use the programmatic session factory (already provided) and then repeat the start-stop of the context and the memory leak test and confirm that webapp is completly gone.

I repeat again. I'm not sure if it is a Dom4J problem or an Hibernate problem, but I think this is a great opportunity (because of the small test-application) to help find the real problem since hibernate get's affected.

Hope we can find a solution to this problem.

thank you all.
Juan Manuel

Environment

linux, jdk 5 and 6, apache tomcat 5.5.x to 7.0

Activity

Show:
JuanJ
September 29, 2010, 5:00 AM
Edited

One more thing I forgot to tell. To build the webapp, maven2 is needed and any JDBC database connection (I use oracle-xe)

Brett Meyer
April 7, 2014, 5:48 PM

In an effort to clean up, in bulk, tickets that are most likely out of date, we're transitioning all ORM 3 tickets to an "Awaiting Test Case" state. Please see http://in.relation.to/Bloggers/HibernateORMJIRAPoliciesAndCleanUpTactics for more information.

If this is still a legitimate bug in ORM 4, please provide either a test case that reproduces it or enough detail (entities, mappings, snippets, etc.) to show that it still fails on 4. If nothing is received within 3 months or so, we'll be automatically closing them.

Thank you!

Brett Meyer
July 8, 2014, 3:10 PM

Bulk rejecting stale issues. If this is still a legitimate issue on ORM 4, feel free to comment and attach a test case. I'll address responses case-by-case. Thanks!

Assignee

Unassigned

Reporter

JuanJ

Fix versions

None

Labels

None

backPortable

None

Suitable for new contributors

None

Requires Release Note

None

Pull Request

None

backportDecision

None

Components

Affects versions

Priority

Major
Configure