• Bug
  • Status: Closed
  • 2 Major
  • Resolution: Fixed
  • ehcache-core
  • alexsnaps
  • Reporter: alfreds
  • June 22, 2011
  • 0
  • Watchers: 0
  • July 27, 2012
  • July 11, 2011

Description

I wrote in the forum about this with details. I’ll restate below just in case. http://forums.terracotta.org/forums/posts/list/5608.page

Does anyone know if this issue has been resolved in newer versions? The point of NPE is net.sf.ehcache.management.Cache:line-61 A careful trace shows that if you add a BlockingCache to the CacheManager (assume same manager that ManagementService is using) it will cause a later NPE after ManagementService has been notified of an add. Since BlockingCache implements Ehcache and does not extend Cache it means as it’s being added to CacheManager:line-818 it is not added to the internal “caches” map. Later down the line when the cache-add listener (ManagementService) gets notified it makes an expectation that the cache in question will be in that net.sf.ehcache.Cache only “caches” map, and of course it isn’t so NPE at net.sf.ehcache.management.Cache:line-61

…

Looking a bit deeper at future versions (2.4.2 for example) this doesn’t seem to have been addressed.

http://svn.terracotta.org/svn/ehcache/trunk/core/src/main/java/net/sf/ehcache/management/ManagementService.java

I’ve also found that there doesn’t appear to be any specific reason why the management package can’t check the “ehcache” map in addition to the already checked “cache” map. In fact I wrote an example which does just that and it appears to work well. I’ll submit a bug on this.

Comments

Fiona OShea 2011-06-28

What do you think?

Alexander Snaps 2011-06-28

Yeah, I’ve been involved in this with this guy on the forums as you could tell… I asked Greg for any historical reason to this, but without any answers and now he’s on vacation. I’ll take a crack at this. Either I can identify some reason for this being the way it is, or I’ll just make the change. Hoping for Greg to answer before the beta… Worst comes worst and users will complain :(

Alfred Stappenbeck 2011-08-31

I just found out that besides r4332 my issue was fixed in at least 2.4.2 (the only version I’ve looked in). It’s fixed due to “net.sf.ehcache.CacheManager” having a different implementation of “getCache(String name)”. At some point it looks like the two separate maps of caches (“ehcaches” and “caches”) were taken out and replaced with just the use of the member map “ehcaches”. There is a comment in net.sf.ehcache.CacheManager that reads “Since version ehcache-core-2.1.0, when an {@link Ehcache} decorator is present in the CacheManager, its not necessary that a…”. So that kind of suggests it may have been fixed in 2.1.0 as well.