When I fired 100 WebDAV requests in 100 threads concurrently, I saw a
deadlock like below :
Found one Java-level deadlock:
=============================
"http-8080-46":
waiting to lock monitor 0x68a52694 (object 0x7365e870, a
org.apache.jackrabbit.core.state.NodeState),
which is held by "http-8080-17"
"http-8080-17":
waiting to lock monitor 0x0810b964 (object 0x7365d3d0, a
java.lang.Object),
which is held by "http-8080-46"
"http-8080-46":
at
org.apache.jackrabbit.core.state.NodeState.getChildNodeEntry(NodeState.java)
- waiting to lock <0x7365e870> (a
org.apache.jackrabbit.core.state.NodeState)
at org.apache.jackrabbit.core.CachingHierarchyManager.nodeModified
- locked <0x7365d3d0> (a java.lang.Object)
at org.apache.jackrabbit.core.CachingHierarchyManager.stateModified
at
org.apache.jackrabbit.core.state.StateChangeDispatcher.notifyStateModified
at
org.apache.jackrabbit.core.state.SessionItemStateManager.stateModified
at
org.apache.jackrabbit.core.state.StateChangeDispatcher.notifyStateModified
at
org.apache.jackrabbit.core.state.LocalItemStateManager.stateModified
at
org.apache.jackrabbit.core.state.StateChangeDispatcher.notifyStateModified
at
org.apache.jackrabbit.core.state.SharedItemStateManager.stateModified
......
"http-8080-17":
at org.apache.jackrabbit.core.CachingHierarchyManager.nodeRemoved
- waiting to lock <0x7365d3d0> (a java.lang.Object)
at
org.apache.jackrabbit.core.state.StateChangeDispatcher.notifyNodeRemoved
at
org.apache.jackrabbit.core.state.SessionItemStateManager.nodeRemoved
at org.apache.jackrabbit.core.state.NodeState.notifyNodeRemoved
at org.apache.jackrabbit.core.state.NodeState.notifyNodeRemoved
at org.apache.jackrabbit.core.state.NodeState.removeChildNodeEntry
- locked <0x7365e870> (a org.apache.jackrabbit.core.state.NodeState)
at org.apache.jackrabbit.core.NodeImpl.removeChildNode
at org.apache.jackrabbit.core.ItemImpl.internalRemove
......
Seems to me, each WebDAV request should create a new DavSession which
creates a new JcrSession always. So different CachingHierarchyManager
instance should be created in any WebDAV request. Why two WebDAV requests
worked on same CachingHierarchyManager and NodeState (container is
SessionISM) instance here? What's the relationship among HttpSession,
DavSession and JcrSession?
--
View this message in context:
http://www.nabble.com/Concurrent-DavSession-tp22773880p22773880.html
Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.