You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Jukka Zitting (JIRA)" <ji...@apache.org> on 2006/11/29 10:28:22 UTC
[jira] Reopened: (JCR-614) Weird locking behaviour in
CachingHierarchyManager
[ http://issues.apache.org/jira/browse/JCR-614?page=all ]
Jukka Zitting reopened JCR-614:
-------------------------------
> 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