jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tobias Bocanegra (JIRA)" <j...@apache.org>
Subject [jira] Created: (JCR-614) Weird locking behaviour in CachingHierarchyManager
Date Wed, 01 Nov 2006 10:24:17 GMT
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

        

Mime
View raw message