• Bug
  • Status: Closed
  • 0 Showstopper
  • Resolution: Fixed
  • ehcache-core
  • nrana
  • Reporter: amiller
  • October 15, 2009
  • 0
  • Watchers: 1
  • November 23, 2009
  • October 30, 2009

Description

I’m seeing this occasionally come up while testing some stuff with EHC-421. Stack trace:

Caused by: java.lang.NullPointerException at java.util.concurrent.ConcurrentHashMap.hash(ConcurrentHashMap.java:157) at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:730) at net.sf.ehcache.store.MemoryStore.findEvictionCandidate(MemoryStore.java:576) at net.sf.ehcache.store.MemoryStore.removeElementChosenByEvictionPolicy(MemoryStore.java:531) at net.sf.ehcache.store.MemoryStore.doPut(MemoryStore.java:461) at net.sf.ehcache.store.MemoryStore.put(MemoryStore.java:150) at net.sf.ehcache.Cache.put(Cache.java:872) at net.sf.ehcache.Cache.put(Cache.java:807) at net.sf.ehcache.jcache.JCache.put(JCache.java:637) at net.sf.ehcache.jcache.JCache.put(JCache.java:606)

Seems like MemoryStore.findEvictionCandidate() sampled eviction has some kind of race in it that can cause this. At a glance, this looks like a race from the independent keyArray (AtomicReferenceArray) and keySamplePointer (AtomicInteger). Could probably patch it with an NPE check and look at a better concurrency fix later. We have similar logic in DistributedCache so that might be a source of ideas.

Comments

Steve Harris 2009-10-15

Should this be in 1.7.1?

Alex Miller 2009-10-30

I was able to reliably reproduce this with with JCacheTest and with the fix I can no longer reproduce it. This is a race that can occur when a clear() comes in during a put() that causes eviction. clear() clears the map but there is no synchronization between that and the updates of the keyArray. Added a null check in the eviction algorithm is sufficient and equally valid.

Nitin Rana 2009-11-23

Verified with the jcachetest. Now there is no NPE.