Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
2 Major
-
Resolution: Fixed
-
Affects Version/s: 2.5.0
-
Fix Version/s: 2.5.1
-
Component/s: ehcache-core
-
Labels:None
-
Terracotta Target:Ehcache 2.5.1
-
Fixed In Revision:trunk:5000 ehcache-core-2.5.x:5001
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.
Issue Links
- is duplicated by
-
EHC-942
Deadlock when used as hibernate 2nd level cache provider
-
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)
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.<init>(WGDocument.java:637)
at de.innovationgate.webgate.api.WGContent.<init>(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?