Terracotta Discussion Forums

Hi there,

we are currently experiencing some very weird phenomenon with our usage of a sizeof-based Ehcache, which only manifests on 64-bit JVMs (Oracle/OpenJDK Hotspot 1.6.0). We are using ehcache-spring-annotations to cache the result of a simple method invocation, which returns a list of Hibernate entities:

List<SomeEntity> getSomeEntities();

SomeEntity only has Strings, Classes and other simple types as fields except for a OneToMany relationship to another Hibernate entity, which just contains Strings. We are using Hibernate.initialize to make sure that the OneToMany relationship is initialized before it is getting cached.

Our cache has a global maxBytesLocalHeap set, so a sizeof measurement takes place before caching.

This works well and is fast on a 32-bit JVM, but on a 64-bit JVM the ObjectGraphWalker spends multiple minutes walking the object graph for the List<SomeEntity> and eventually hits the depth limit of 1000.

I am a bit lost trying to figure out what is wrong (a heap dump captured via Visual VM does not seem to contain the objects currently on the stack).

Is sizeof measurement any different between 32 and 64bit?

Thanks,
Thilo

P.S.: Ehcache 2.5.1

That sounds quite bizarre that you get different results by only switching from a 32 bit JVM to the exact same but 64 bit version of that JVM.

Could you please post the exact JVM version you're using, both for the 32 and 64 bit ones? Could you please also include all the command-line args you're passing to the JVM as some might cause the problem?

You can also have a good idea of what the sizeof engine is doing by setting the net.sf.ehcache.sizeof.verboseDebugLogging system property to true and enabling debug logs on net.sf.ehcache.pool.sizeof. That will certainly help figuring out what objects the sizeof engine is sizing that it shouldn't. Beware that this is generate a very large amount of logs.

After some further investigation the sizeof issue seems to occur on both 32 and 64 bit VMs. It just caught our attention on 64 bit, which is a lot more slower for this operation (probably it is spending considerably more time on GC as -Xmx is the same for both).

The root cause of the issue has also been identified. The association from SomeEntity to OtherEntity is represented as a org.hibernate.collection.PersistentList, which contains a reference to a session that effectively pulls in the whole Spring context. AFAICS the session is cleared when the entity is detached from the session, so I am currently looking for an elegant solution to achieve this session detachment while still retainign the declarative approach of the ehcache-spring-annotations.

Has someone else already encountered such a situation and could share his approach?

You could simply instruct ehcache's sizeof engine to ignore the session field of the Hibernate PersistentList.

Here's the doc that explains how to configure the ignore rules: http://ehcache.org/documentation/configuration/cache-size#built-in-sizing-computation-and-enforcement

While we could certainly do that this would mean that we have Hibernate entities in the cache that are still attached to a session (as a race condition until the original Hibernate session has been completed, which will detach the entity). I don't want to imagine what side-effects could result from this. ;-)