jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcel Reutegger (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (JCR-3617) Inconsistent CachingHierarchyManager under concurrent access
Date Wed, 03 Jul 2013 09:20:19 GMT

     [ https://issues.apache.org/jira/browse/JCR-3617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Marcel Reutegger resolved JCR-3617.
-----------------------------------

       Resolution: Fixed
    Fix Version/s: 2.7.1

Discussed with Dominique Pfister and he suggested to also evict the cache entry when the CachingHierarchyManager
detects a potentially stale entry. Furthermore, we decided to lower warn level of the 'overwriting
PathMap.Element' log message to debug. With the current concurrency control in Jackrabbit
it is in fact possible that a CachingHierarchyManager has stale entries for some time, which
are later replaced with more recent data.

Committed refined fix in http://svn.apache.org/r1499285
                
> Inconsistent CachingHierarchyManager under concurrent access
> ------------------------------------------------------------
>
>                 Key: JCR-3617
>                 URL: https://issues.apache.org/jira/browse/JCR-3617
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-core
>    Affects Versions: 2.2, 2.4, 2.6
>            Reporter: Marcel Reutegger
>            Assignee: Marcel Reutegger
>            Priority: Minor
>             Fix For: 2.7.1
>
>
> This is a bit difficult to reproduce and so far I'm not able to provide a standalone
test case for this issue. However, the following happens on the application level: a sub-tree
is replaced with a modified version of the sub-tree while event listeners track those changes
and try to get items for the given event paths. In some cases the repository throws an exception
when Session.getItem() is called similar to what was reported in JCR-3368.
> It is important to note that the replaced subtree has some special characteristics. The
root node of the sub-tree is re-created with the same UUID, while descendant nodes may be
replaced with different UUIDs, but still have the same name.
> There seems to be a short time window where the modifying Session saves this kind of
change, which gets propagated up to the ItemState layers and into the CachingHierarchyManager
and the listening Session (owning the CachingHierarchyManager) access modified items at the
same time through the CachingHierarchyManager. In some cases this seems to create an inconsistent
state in the CachingHierarchyManager where a path is mapped to the old UUID (and vice versa)
even though the replace already happened.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message