Return-Path: X-Original-To: apmail-jackrabbit-dev-archive@www.apache.org Delivered-To: apmail-jackrabbit-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id CE3F410E75 for ; Tue, 2 Jul 2013 08:52:58 +0000 (UTC) Received: (qmail 48347 invoked by uid 500); 2 Jul 2013 08:52:38 -0000 Delivered-To: apmail-jackrabbit-dev-archive@jackrabbit.apache.org Received: (qmail 48056 invoked by uid 500); 2 Jul 2013 08:52:16 -0000 Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@jackrabbit.apache.org Delivered-To: mailing list dev@jackrabbit.apache.org Received: (qmail 47630 invoked by uid 99); 2 Jul 2013 08:50:41 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 02 Jul 2013 08:50:41 +0000 Date: Tue, 2 Jul 2013 08:50:39 +0000 (UTC) From: "Marcel Reutegger (JIRA)" To: dev@jackrabbit.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (JCR-3617) Inconsistent CachingHierarchyManager under concurrent access MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/JCR-3617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13697613#comment-13697613 ] Marcel Reutegger commented on JCR-3617: --------------------------------------- Added (disabled) test in revision 1498840. > 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 > > 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