Return-Path: 
 <dev-return-5732-apmail-curator-dev-archive=curator.apache.org@curator.apache.org>
X-Original-To: apmail-curator-dev-archive@minotaur.apache.org
Delivered-To: apmail-curator-dev-archive@minotaur.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 0FE9418E1D
	for <apmail-curator-dev-archive@minotaur.apache.org>;
 Mon,  1 Feb 2016 19:24:20 +0000 (UTC)
Received: (qmail 58908 invoked by uid 500); 1 Feb 2016 19:17:40 -0000
Delivered-To: apmail-curator-dev-archive@curator.apache.org
Received: (qmail 58856 invoked by uid 500); 1 Feb 2016 19:17:40 -0000
Mailing-List: contact dev-help@curator.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@curator.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@curator.apache.org>
List-Post: <mailto:dev@curator.apache.org>
List-Id: <dev.curator.apache.org>
Reply-To: dev@curator.apache.org
Delivered-To: mailing list dev@curator.apache.org
Received: (qmail 58826 invoked by uid 99); 1 Feb 2016 19:17:39 -0000
Received: from arcas.apache.org (HELO arcas) (140.211.11.28)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 01 Feb 2016 19:17:39 +0000
Received: from arcas.apache.org (localhost [127.0.0.1])
	by arcas (Postfix) with ESMTP id D05432C0AFA
	for <dev@curator.apache.org>; Mon,  1 Feb 2016 19:17:39 +0000 (UTC)
Date: Mon, 1 Feb 2016 19:17:39 +0000 (UTC)
From: "Scott Blum (JIRA)" <jira@apache.org>
To: dev@curator.apache.org
Message-ID: <JIRA.12934850.1453999295000.267287.1454354259849@Atlassian.JIRA>
In-Reply-To: <JIRA.12934850.1453999295000@Atlassian.JIRA>
References: <JIRA.12934850.1453999295000@Atlassian.JIRA>
 <JIRA.12934850.1453999295803@arcas>
Subject: [jira] [Resolved] (CURATOR-294) Optimize TreeCache, fix possible
 concurrency issue
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/CURATOR-294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Blum resolved CURATOR-294.
--------------------------------
    Resolution: Fixed

> Optimize TreeCache, fix possible concurrency issue
> --------------------------------------------------
>
>                 Key: CURATOR-294
>                 URL: https://issues.apache.org/jira/browse/CURATOR-294
>             Project: Apache Curator
>          Issue Type: Improvement
>          Components: Recipes
>            Reporter: Nick Hill
>            Assignee: Scott Blum
>             Fix For: 3.0.1, 2.9.2
>
>
> Hi, I have been looking at the TreeCache impl and have some questions.
> It doesn't look right to me that there's separate atomic refs for a node's data and stat. It seems the stat in a ChildData object obtained from getCurrentData() might not correspond to the data that it's with. This could be problematic when doing conditional state changes given assumptions about that data.
> An obvious and simple solution to this would be to have a single AtomicReference<ChildData> field instead, which would have the additional significant benefit of eliminating ChildData obj creation on every cache access. PathChildrenCache works this way, but my understanding was that TreeCache is intended to be a (more flexible) replacement.
> Furthermore I'd propose that the data field of ChildData be just a final byte[] instead of an AtomicReference. This would avoid needing two volatile reads to get to the data, and mean that "sharing" these (per above) is a bit safer. The ChildData byte[] AtomicReference is only used by PathChildrenCache.clearDataBytes() (not currently used by TreeCache at all), and that capability could be easily maintained by having PathChildrenCache use it's own simple subclass of ChildData containing the atomic reference.
> If similar capability were to be added to TreeCache, I'd suggest it would be better to just replace the node's ChildData object with a copy that has the byte[] field nulled out (but same stat ref).
> I'm fairly new to the code so apologies if there's something I've missed/misunderstood! But if there is agreement, I'd also be happy to prepare a PR.
> Regards,
> Nick



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)