-
Bug
-
Resolution: Done
-
Major
-
12.0.1.Final
-
None
-
None
On a high throughput application, the systematic usage of CacheContainer.getCache(String cacheName) to access any entry leads to a huge contention on DefaultCacheManager.lifecycleLock .
In the jstack we see 30 threads waiting on DefaultCacheManager.lifecycleLock :
"xxxx@http-nio2-8080-exec-112" #76183 daemon prio=5 os_prio=0 cpu=829450.84ms elapsed=39272.79s tid=0x00007f931c001000 nid=0x2b08 waiting on condition [0x00007f9351ad7000] java.lang.Thread.State: WAITING (parking) at jdk.internal.misc.Unsafe.park(java.base@11.0.11/Native Method) - parking to wait for <0x00007fa1ffa0acc8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync) at java.util.concurrent.locks.LockSupport.park(java.base@11.0.11/LockSupport.java:194) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(java.base@11.0.11/AbstractQueuedSynchronizer.java:885) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(java.base@11.0.11/AbstractQueuedSynchronizer.java:917) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(java.base@11.0.11/AbstractQueuedSynchronizer.java:1240) at java.util.concurrent.locks.ReentrantLock.lock(java.base@11.0.11/ReentrantLock.java:267) at org.infinispan.manager.DefaultCacheManager.internalStart(DefaultCacheManager.java:725) at org.infinispan.manager.DefaultCacheManager.internalGetCache(DefaultCacheManager.java:521) at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:510)
Is that expected?