[ http://issues.apache.org/jira/browse/JCR-614?page=all ]
Jukka Zitting updated JCR-614:
------------------------------
Affects Version/s: 1.1.1
> 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, 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
