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

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


View raw message