• Bug
  • Status: Closed
  • 2 Major
  • Resolution: Fixed
  • ehcache-core
  • cdennis
  • Reporter: asauvez
  • November 29, 2011
  • 0
  • Watchers: 3
  • July 27, 2012
  • November 29, 2011

Description

In net.sf.ehcache.store.chm.SelectableConcurrentHashMap$MemoryStoreSegment.unpinAll() :

    public void unpinAll() {
        writeLock().lock();
        if(numDummyPinnedKeys == count) {
            clear();
            return;
        }
        try {
            // (...)
        } finally {
            writeLock().unlock();
        }
    }

If the first if returns (and it happens), the lock remains lock, freezing all future access to the cache. The “writeLock().lock();” should only be done just before the try/finally. It seems to be a regression on 2.5.0, since the exact same sequence with prior version worked just fine.

Comments

Oliver Weise 2012-06-27

Unfortunately we seem to see this issue still in EHCache 2.5.2 while using EHCache as direct caching API. We are having a deadlock with the same stack information as was already documented with issue EHC-942:

“TP-Processor340” daemon prio=10 tid=0x00007fd305d4a000 nid=0x3dd8 waiting on condition [0x00007fd2f490b000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x0000000680619bf0> (a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:811) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:842) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1178) at java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:807) at net.sf.ehcache.store.FrontEndCacheTier.remove(FrontEndCacheTier.java:306) at net.sf.ehcache.Cache.removeInternal(Cache.java:2365) at net.sf.ehcache.Cache.remove(Cache.java:2278) at net.sf.ehcache.Cache.remove(Cache.java:2203) at net.sf.ehcache.Cache.remove(Cache.java:2181) at de.innovationgate.utils.cache.EHCacheCore.flushEntry(EHCacheCore.java:179) at de.innovationgate.utils.cache.Cache.flushEntry(Cache.java:88) at de.innovationgate.webgate.api.WGAPIGenericCache.flushDocumentCache(WGAPIGenericCache.java:266) at de.innovationgate.webgate.api.WGDocument.dropCache(WGDocument.java:584) at de.innovationgate.webgate.api.WGContent.dropCache(WGContent.java:455) at de.innovationgate.webgate.api.WGDocument.(WGDocument.java:637) at de.innovationgate.webgate.api.WGContent.(WGContent.java:407) at de.innovationgate.webgate.api.WGDatabase.getDummyContent(WGDatabase.java:5053) at de.innovationgate.wgpublisher.WGPDispatcher.dispatchTmlRequest(WGPDispatcher.java:1331) at de.innovationgate.wgpublisher.WGPDispatcher.doGet(WGPDispatcher.java:1046) at de.innovationgate.wgpublisher.WGPDispatcher.doPost(WGPDispatcher.java:731)

Just to be sure we use the right version we checked to the row numbers in this stack. The row number on FrontEndCacheTier identifies it as EHCache 2.5.2.

There are several threads with equals stacks trying to do various cache operations.

As we are using EHCache directly and not via Hibernate: Is it possible that we introduce this deadlock possibility with our usage scheme?

Chris Dennis 2012-06-27

Yes it is possible to cause a deadlock through misuse of the Ehcache explicit locking APIs. With this fact in mind, if you believe the issue to be caused by your use of Ehcache then it’s probably best if we move this discussion to the forums (http://forums.terracotta.org). If you believe however that this is a bug in Ehcache, then you should file a new issue in JIRA to track it. This issue is closed, and is related to a bug that no longer exists in 2.5.2 - if this is an Ehcache bug then it’s a distinct issue from this one.