Leaks when combined with dependencies into one jar

Description

Attached is an example project that simply opens an EntityManagerFactory and closes it, forever, with no entity classes.

When this project is built into a single jar, including Hibernate and its dependencies, an increasing amount of memory is used outside of the Java heap, up to several GB, and this does not happen when the project is run as separate jars. As the screenshot shows, the memory appears in ps as resident, but does not appear in JVisualVM's graph of the heap size. (It's also not in the PermGen, although that's not in the screenshot.)

Adjust the DB details at the top of RunHibernate.java, run ant dist to build, and then run run-combined.sh or run-separate.sh, and note the different memory behaviour.

We have seen this on both Java 7 and Java 8. Also, the project does not seem to leak on OSX.

Attachments

3
  • 06 Jan 2016, 02:30 PM
  • 05 Jan 2016, 03:38 PM
  • 05 Jan 2016, 03:38 PM

Activity

Show:

Steve Ebersole February 28, 2016 at 12:09 AM

And the simple fact is that we don't distribute Hibernate that way. If there is a leak and/or problem I am all for finding it and fixing it, but as it seems to happen only when distributed other than how we distribute it I personally don't have the time right now to put into this. it would be awesome if you want this fixed to help identify what exactly happens in what you do that causes this to become an issue.

Scott Marlow February 26, 2016 at 1:48 PM

You are monitoring the Java process memory size, which is interesting but doesn't really give Java level details. It would be more interesting if you generate a Java heap dump and examine that with a tool like the Eclipse Memory Analyzer Tool.

I don't really understand what the difference is between using a single jar and separate jars that leads to increased memory use as you open/close the entitymanagerfactory in a loop. I'm guessing that there is no real difference except the Java process memory is increasing.

+1 for closing the JarInputStreams, but your patch reformatted more lines than needed.

Chris Boyle January 7, 2016 at 1:45 PM

Setting hibernate.ejb.resource_scanner to an implementation that returns static results and doesn't do any scanning works around the problem for us, which suggests the leak is somewhere in scanning.

Chris Boyle January 6, 2016 at 2:31 PM
Edited

We found a couple of unclosed JarInputStreams while looking at this. Closing them does not seem to fix the leak, but seems like it should be done anyway, so here is the patch for that.

Rejected

Details

Assignee

Reporter

Affects versions

Priority

Created January 5, 2016 at 3:46 PM
Updated January 22, 2025 at 6:35 PM
Resolved January 22, 2025 at 6:35 PM