Status: Verified (View Workflow)
Affects Version/s: 7.0.1.CR1
Steps to Reproduce:
1. deploy an application using JPA with Hibernate second level cache enabled
2. use the second level cache (I'm note sure if this step is really needed)
3. undeploy the application
4. take a heap dump
5. search for incoming references to SessionFactoryImpl
Git Pull Request:
We are using Hibernate second level cache through JPA configured as such:
After heap dump inspection, it seems that the JGroups ForkChannel identified by "hibernate" can hold a listener that hold the SessionFactoryImpl which then hold the whole application classloader.
When undeploying the application, this can lead to classloader leak.
I took an heap dump of such scenario and analysed it using eclipse memory analyzer (MAT) and here is the result:
To remove that leak I ugily patched JGroups ForkChannel close method as such:
With that change in place, the memory leak is gone. I highly doubt though this is an acceptable fix. Though it does confirm my theory.
I doubt that JGroups is really the culprit – I'm more in the thinking that the "thing managing" JGroups is the culprit.
Since I'm not an expert around that field I've opened the issue against the Wildfly project. Feel free to move it to the proper project.
If you need any other informations let me know.