• Bug
  • Status: New
  • 2 Major
  • Resolution:
  • ljacomet
  • Reporter: kmacleod
  • October 16, 2013
  • 0
  • Watchers: 3
  • November 04, 2013

Description

When {{DefaultSizeOfEngine}} logs a {{MaxDepthExceededException}}, it logs something like the following:

{noformat} The configured limit of 100 object references was reached while attempting to calculate the size of the object graph. This can be avoided by adding stop points with @IgnoreSizeOf annotations. Since the CacheManger or Cache elements maxDepthExceededBehavior is set to "abort", the sizing operation has stopped and the reported cache size is not accurate. 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. key type: java.lang.Long key: 1977257820 value type: net.sf.ehcache.Element value: [ key = 1977257820, value=Item\{version=null,freshTimestamp=5659797483282457, version=1, hitCount=3, CreationTime = 1381786494942, LastAccessTime = 1381786542030 ] container: net.sf.ehcache.store.chm.SelectableConcurrentHashMap$HashEntry@3b6b87b6 \{noformat\}

Very little of this information is of any help in diagnosing the problem:

The “value type” is probably always going to be {{net.sf.ehcache.Element}}. The logging needs to unwrap the {{Element}} and report on the type inside it.

The “value” is a dangerous thing to log. If this logging code is being executed, then there’s a strong chance that the value is very large, and it should not be logged (certainly not at WARN level).

The “container” line is no help whatsoever - it’s an undefined toString of an internal ehcache data structure. A much more useful thing to log here would be the human-readable representation of the cache (i.e. the cache name).

Comments