]
Juan Alvarez Gimenez commented on HHH-5601:
-------------------------------------------
One more thing I forgot to tell. To run the webapp, maven2 is needed and any JDBC database
connection (Here I use oracle-xe)
Memory leak when building session factory from xml, classloader does
not get garbage-collected
----------------------------------------------------------------------------------------------
Key: HHH-5601
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HHH-5601
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.3.2, 3.5.1
Environment: linux, jdk 5 and 6, apache tomcat 5.5.x to 7.0
Reporter: Juan Alvarez Gimenez
Attachments: leakwebapp.zip
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
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: