well, finally i was forced to track down a heap leak in my site engine. i had been doing persistence in my Java stack through Hibernate, but was using XDoclet annotations which required a build step. it was nice — it generated all the HBM config which i could then use to erect a Session in Groovy scripts — but i decided to move to the JPA. here’s a dump of thoughts and keywords to hopefully save someone else the pain

so, i knew that i had a heap leak with current site weaving with Hibernate 3.2 and JOTM 2.0.10. it was somehow related to Hibernate interacting with the JTA; as long as i stayed non-transactional, i had no leak. i just kept this line out of my Hibernate config:

hibernate.transaction.manager_lookup_class = com.sleepbot.ambience.spring.TransactionManagerLookupBridge

that’s a story in and of itself (note the site-specific class) … grep on the Hibernate setting for more info.

now as i went to using Hibernate’s EntityManager impl, i was required to use a JTA Transaction manager. i couldn’t pull that non-transactional trick anymore. and when Hibernate knew about the JTA, my app would fall over after a few days worth of activity. so i spent a good number of hours on Superbowl Sunday tracking this baby down. i have another Spring + JPA + JOTM stack that doesn’t exhibit the memory leak, so i used it as reference. (yes, i know JOTM hasn’t been touched since May 2005 and it’s not a ‘full’ transactional authority when it comes to rollbacks, but i’ll change that up later.) fortunately, i had moved to running Tomcat under J2SE 6 so there were nice tools to help me out

first thing i did was use jmap -histo:live to identify that there was one of each of these per request:

org.hibernate.impl.SessionImpl

very repeatable. so i used jmap -dump:live,format=b,file=... to get some hprof output, and started up jhat to do some traversal. i definitely needed to extablish a minimum heap size via the -J property proxy and -baseline helped me see what new objects had appeared between dumps. the SessionImpl this was tied to an EntityManagerImpl and a TransationImpl respectively, and a network of other fun classes. i noticed that a lot of these elements were tied the synchroList of an instance of:

org.objectweb.jotm.SubCoordinator

and these bad boys were being leveraged as keys into the static tieCache map of:

com.sun.corba.se.impl.util.Utility

of course i wasn’t doing this, and Eclipse helped me to see that no matter how hard i GCd, those SubCoordinators were not being released. so i had my memory leak. but what the heck?

turns out that SubCoordinator is a PortableRemoteObject which automatically export itself to a delegating implementation that it identifies via:

javax.rmi.PortableRemoteObject.createDelegateIfSpecified("javax.rmi.CORBA.PortableRemoteObjectClass")

and within my app, that was resolving to the default

com.sun.corba.se.impl.javax.rmi.PortableRemoteObject

which performed registration via the Utility above. each SubCoordinator was tied to a CACHE_MISS singleton; nothing good was coming of this. and then i found:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6534290
http://mail-archive.ow2.org/jotm/2004-09/msg00065.html

so this is known problem with CACHE_MISSes. great. so, what to i do? again, this had been answered:

http://mail-archive.ow2.org/jotm/2003-02/msg00055.html

as long as i start up the JVM as follows:

-Djavax.rmi.CORBA.PortableRemoteObjectClass=org.objectweb.carol.rmi.multi.MultiPRODelegate
-Djava.naming.factory.initial=org.objectweb.carol.jndi.spi.MultiOrbInitialContextFactory

then JOTM registers itself as the PortableRemoteObject delegate, which doesn’t take the foolish caching step. hooray! no more leak!

strangely enough i haven’t had to use those Java properties on other working stacks. i have no idea why mine required explicit qualification

so there. hopefully that’ll point someone else in the right direction. with things like this it’s a matter of having the right tools and choosing the right search terms

peace

Your response: