• Bug
  • Status: New
  • 2 Major
  • Resolution:
  • drb
  • Reporter: taman01
  • January 18, 2017
  • 0
  • Watchers: 2
  • April 14, 2017


If there any specific reason why blockingCache.get() call getting stuck. Will the problem resolved in later version.

[1/6/17 10:43:29:860 EST] 00000040 ThreadMonitor W WSVR0605W: Thread “WebContainer : 1” (000001db) has been active for 747477 milliseconds and may be hung. There is/are 1 thread(s) in total in the server that may be hung. at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:182) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:822) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:952) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1272) at java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(ReentrantReadWriteLock.java:694) at net.sf.ehcache.concurrent.ReadWriteLockSync.lock(ReadWriteLockSync.java:50) 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 com.netegrity.llsdk6.imsimpl.securityengine.AuthorizationCacheManager.getStoredUserTasks(AuthorizationCacheManager.java:637)


Anupam Tamrakar 2017-01-18

More from CA Technologies. We noticed this terracotta posting from many years ago. http://forums.terracotta.org/forums/posts/list/4502.page

We are running version 2.5.2. We are wondering if the GC or jdk observations made on this posting pertain to this much later version.

Also, please note that the problem described in our previous posting occurred on WAS We are also consulting with IBM – just putting this out there in case anyone has had problems with ehCache 2.5.+ on WAS 8.5.5.

Louis Jacomet Jacomet 2017-04-14

-The whole point of the blocking cache is that it will _block_ on a {{get}} until there is something to return.- -So you are expected to be putting an entry at some point from another thread.- Sorry, that was written to fast and is wrong.

The first thread for which {{get}} returns {{null}} will keep a lock, blocking all subsequent {{get}} on the same key from other threads. The thread that saw the {{null}} return _must_ {{put}} a value in order to unblock all blocked {{get}}.

Note that other threads will also be blocked from doing a {{put}}.

Why are you using a {{BlockingCache}}?