Marcel Reutegger created JCR-3617:
-------------------------------------
Summary: 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.6, 2.4, 2.2
Reporter: Marcel Reutegger
Assignee: Marcel Reutegger
Priority: Minor
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
