Mailing-List: contact notifications-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jira@apache.org
Date: Mon, 26 Jan 2015 20:56:35 +0000 (UTC)
From: "Josh Elser (JIRA)" <jira@apache.org>
To: notifications@accumulo.apache.org
Message-ID: <JIRA.12769774.1422056137000.176197.1422305795313@Atlassian.JIRA>
In-Reply-To: <JIRA.12769774.1422056137000@Atlassian.JIRA>
References: <JIRA.12769774.1422056137000@Atlassian.JIRA>
 <JIRA.12769774.1422056137479@arcas>
Subject: [jira] [Commented] (ACCUMULO-3530) alterTable/NamespaceProperty
 should use Fate locks
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/ACCUMULO-3530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14292403#comment-14292403 ] 

Josh Elser commented on ACCUMULO-3530:
--------------------------------------

Makes sense: the state/config of the source table when the cloneTable() is started should be the same as the config on the resulting cloned table, right?

> alterTable/NamespaceProperty should use Fate locks
> --------------------------------------------------
>
>                 Key: ACCUMULO-3530
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-3530
>             Project: Accumulo
>          Issue Type: Bug
>            Reporter: John Vines
>
> Fate operations, such as clone table, have logic in place to ensure consistency as the operation occurs. However, operaitons like alterTableProperty can still interfere because there is no locking done. We should add identical locking to these methods in MasterClientServiceHandler to help ensure consistency.


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