Weird locking behaviour in CachingHierarchyManager
--------------------------------------------------
Key: JCR-614
URL: http://issues.apache.org/jira/browse/JCR-614
Project: Jackrabbit
Issue Type: Bug
Components: core
Affects Versions: 1.0.1, 1.1
Reporter: Tobias Bocanegra
Assigned To: Tobias Bocanegra
Fix For: 1.2
in some of our itegration tests the repository sometime locks-up with a
stacktrace like this:
"Thread-38" daemon prio=5 tid=0x08cb3908 nid=0xdd8 runnable [9fef000..9fefd90]
at
org.apache.jackrabbit.core.CachingHierarchyManager.removeLRU(CachingHierarchyManager.java:540)
- waiting to lock <0x16a9b0e0> (a java.lang.Object)
at
org.apache.jackrabbit.core.CachingHierarchyManager.cache(CachingHierarchyManager.java:510)
- locked <0x16a9b0e0> (a java.lang.Object)
at
org.apache.jackrabbit.core.CachingHierarchyManager.buildPath(CachingHierarchyManager.java:163)
at
org.apache.jackrabbit.HierarchyManagerImpl.buildPath(HierarchyManagerImpl.java:296)
[...]
although i think that this sacktrace is valid (a thread holding a monitor
waiting to lock it again) this scenario shows up a lot during stress-testing. i
assume it's the JIT that messesup synchornization.
the fix is to remove the double monitor entry in this case.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
