IgnoreSizeOf annotation when using ehcache with terracotta

Question

I am using ehcache with terracotta in my application. My response time increased by 700 folds when i am using ehcache with terracotta. I think the terracotta is taking time in measuring the size of objects as it giving me warning:

net.sf.ehcache.pool.sizeof.ObjectGraphWalker checkMaxDepth WARNING: The configured limit of 1,000 object references was reached while attempting to calculate the size of the object graph. Severe performance degradation could occur if the sizing operation continues. This can be avoided by setting the CacheManger or Cache elements maxDepthExceededBehavior to "abort" or adding stop points with @IgnoreSizeOf annotations. If performance degradation is NOT an issue at the configured limit, raise the limit value using the CacheManager or Cache elements maxDepth attribute. For more information, see the Ehcache configuration documentation.

When i used @IgnoreSizeOf annotation on my class, the response time reduced to a lot . My question is does using @IgnoreSizeOf annotation has any disadvantages. For what it is being used and how it is reducing the response time of my application Please help. Thanks in advance.

Answer 1

This annotation isn't related to Terracotta clustering. I guess you posted that other question on this subject.

The @IgnoreSizeOf annotation will have the sizeOfEngine, that measures the memory footprint of entries in your caches, ignore instances of annotated classes (or entire packages) or subgraphs (annotated fields) of your cached entries.

So if an object graph that you cache has a "shared" subgraph, you'd annotate the field where that graph starts with the annotation. If you ignore everything then nothing will be sized and the maxBytesLocalHeap setting has no semantic (you'll eventually suffer from OOME).

You need to understand the object graphs you're caching in order to use the annotation properly. See http://ehcache.org/documentation/configuration/cache-size#built-in-sizing-computation-and-enforcement for more details.

Now, to the performance issue you're seeing, you might want to test with and without the maxBytesLocalHeap setting and with and without clustering to try to pin point your problem. But I suspect you might be caching more than you expect, resulting in big men footprint, as well as overhead clustering the data...