Possible deadlock when cache web request with SimplePageCachingFilter

[Alive Substance]

1. ehcache version 2.9.0;
2. <cache name="SimplePageCachingFilter" maxElementsInMemory="100000" eternal="false" overflowToDisk="false" timeToIdleSeconds="300" timeToLiveSeconds="600" memoryStoreEvictionPolicy="LFU" transactionalMode="off"/>;
   
3. pure ehcache
4. java 1.8, ubuntu 14.10

Hi

We are using SimplePageCachingFilter to cache web request. The configuration is above and there is nothing special. The SimplePageCachingFilter use blocking cache inside and twice we got the situation when all thread stucks waiting for a lock. Interesting that all theads are in the WAITING state and there is no thread that acqiure the lock and do some job. You can find stack trace(similar to all threads) below. This value 0x000000035080f750 is the equal for all threads.

Blocking cache use reentrant read write lock to work consistence with cache data. RW lock has an option to get lock with timeout. By default time out set to zero which mean wait indefinitelly to acquire the lock. As a workaround we decided to introduce non zero value for blockingTimeoutMillis property that allow use tryLock() method of RW lock class with timeout. 

Do you have any ideas why we got this strange situation? Do you need more information?

"qtp249034932-92483" #92483 prio=5 os_prio=0 tid=0x00007ff879160000 nid=0x7811 waiting on condition [0x00007ff83d18f000]

   java.lang.Thread.State: WAITING (parking)

at sun.misc.Unsafe.park(Native Method)

- parking to wait for  <0x000000035080f750> (a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)

at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)

at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)

at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)

at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)

at java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(ReentrantReadWriteLock.java:727)

at net.sf.ehcache.concurrent.ReadWriteLockSync.lock(ReadWriteLockSync.java:53)

at net.sf.ehcache.constructs.blocking.BlockingCache.acquiredLockForKey(BlockingCache.java:186)

at net.sf.ehcache.constructs.blocking.BlockingCache.get(BlockingCache.java:151)

at net.sf.ehcache.constructs.blocking.BlockingCache.get(BlockingCache.java:243)

at net.sf.ehcache.constructs.web.filter.CachingFilter.buildPageInfo(CachingFilter.java:242)

at net.sf.ehcache.constructs.web.filter.CachingFilter.doFilter(CachingFilter.java:216)

at net.sf.ehcache.constructs.web.filter.Filter.doFilter(Filter.java:86)

[Alex Snaps]

BlockingCache does "leak" locks "outside" of the Cache... i.e. it's the thread hitting a null responsibility to either populate the cache for the given key, or at least put <null> back in to allow other threads to acquire the said lock. If you aren't using the Cache yourself in anyway, it _could_ be there is a bug in the CachingFilter that doesn't handle this properly.

Could you confirm that nothing in your code interact with that decorated cache ever? If that's the case, best would be to open a bug at https://jira.terracotta.org/jira/browse/EHC/

Thanks,

Alex

--
You received this message because you are subscribed to the Google Groups "ehcache-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ehcache-user...@googlegroups.com.
To post to this group, send email to ehcach...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ehcache-users/00bacfa8-d123-471a-830d-bea862ae52ec%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.