-
Type: Bug
-
Status: Resolved
-
Priority: Minor
-
Resolution: Fixed
-
Affects Version/s: 5.7.1
-
Fix Version/s: 5.5.0-HF19, 5.6.0-HF20, 5.7.2
-
Component/s: WebDAV
Same pb than NXP-11249
one thread loop in a corrupted hashmap with the write lock
"ajp-0.0.0.0-8909-19" daemon prio=10 tid=0x00007f1c59146000 nid=0x4cb6 runnable [0x00007f1c37efc000] java.lang.Thread.State: RUNNABLE at java.util.LinkedHashMap.transfer(LinkedHashMap.java:253) at java.util.HashMap.resize(HashMap.java:564) at java.util.HashMap.addEntry(HashMap.java:851) at java.util.LinkedHashMap.addEntry(LinkedHashMap.java:427) at java.util.HashMap.put(HashMap.java:484) at org.nuxeo.wss.servlet.config.FilterBindingResolver.getBinding(FilterBindingResolver.java:64) at org.nuxeo.wss.servlet.config.FilterBindingResolver.getBinding(FilterBindingResolver.java:48) at org.nuxeo.wss.servlet.BaseWSSFilter.doFilter(BaseWSSFilter.java:115)
while others are waiting on the read lock
"ajp-0.0.0.0-8909-108" daemon prio=10 tid=0x00007f1c5a0d7000 nid=0x1e2b waiting on condition [0x00007f1c21664000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x000000070c942fe0> (a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:964) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1282) at java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(ReentrantReadWriteLock.java:731) at org.nuxeo.wss.servlet.config.FilterBindingResolver.getBinding(FilterBindingResolver.java:55) at org.nuxeo.wss.servlet.config.FilterBindingResolver.getBinding(FilterBindingResolver.java:48)
The writing thread use 100% of the CPU.
LinkedHashMap that overrides removeEldestEntry does not support concurrent read, so using a ReentrantReadWriteLock is not enough, FilterBindingResolver must be fixed.
- depends on
-
NXP-11249 Deadlock + infinite loop in request filter at high load
- Resolved