Return-Path: 
 <notifications-return-30446-apmail-accumulo-notifications-archive=accumulo.apache.org@accumulo.apache.org>
X-Original-To: apmail-accumulo-notifications-archive@minotaur.apache.org
Delivered-To: apmail-accumulo-notifications-archive@minotaur.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id EBDFA183D1
	for <apmail-accumulo-notifications-archive@minotaur.apache.org>;
 Fri, 22 May 2015 20:15:17 +0000 (UTC)
Received: (qmail 82948 invoked by uid 500); 22 May 2015 20:15:17 -0000
Delivered-To: apmail-accumulo-notifications-archive@accumulo.apache.org
Received: (qmail 82905 invoked by uid 500); 22 May 2015 20:15:17 -0000
Mailing-List: contact notifications-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:notifications-help@accumulo.apache.org>
List-Unsubscribe: <mailto:notifications-unsubscribe@accumulo.apache.org>
List-Post: <mailto:notifications@accumulo.apache.org>
List-Id: <notifications.accumulo.apache.org>
Reply-To: jira@apache.org
Delivered-To: mailing list notifications@accumulo.apache.org
Received: (qmail 82884 invoked by uid 99); 22 May 2015 20:15:17 -0000
Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 22 May 2015 20:15:17 +0000
Date: Fri, 22 May 2015 20:15:17 +0000 (UTC)
From: "Keith Turner (JIRA)" <jira@apache.org>
To: notifications@accumulo.apache.org
Message-ID: <JIRA.12831878.1432229677000.13394.1432325717727@Atlassian.JIRA>
In-Reply-To: <JIRA.12831878.1432229677000@Atlassian.JIRA>
References: <JIRA.12831878.1432229677000@Atlassian.JIRA>
 <JIRA.12831878.1432229677731@arcas>
Subject: [jira] [Commented] (ACCUMULO-3842) [UMBRELLA] Remove non-transient
 data from ZooKeeper
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/ACCUMULO-3842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14556765#comment-14556765 ] 

Keith Turner commented on ACCUMULO-3842:
----------------------------------------

bq. ZooKeeper doesn't keep us from accomplishing this.  We would need to write code to actually get the strong consensus for ourselves.

Isn't this statement is true for HDFS also?   Wether using zookeeper or HDFS, config needs to be cached on tservers for efficiency.  For most operations config is not changing, do not want to make a synchronous read to ZK of HDFS before servicing each RPC.  I think we need something at the API level to address this, regardless of implementation.

bq.  but I think we're at the point where this is a problem we need to start thinking about because it's been a repeated problem for ourselves just in writing reasonable tests for Accumulo for ~2years now.

Yes, this is a big problem, lets fix it.   I think ZK provides primitives that make adding an Accumulo API to wait for tservers to synch config to a certain point fairly easy to implement.  I think a good place to start is thinking what the API solutions for this would look like.  Some possible API changes :

 # Add something like  {{waitForConfigSynch(long timeout, TimeUnit tu)}} to the API.  If it times out could throw an exception w/ info about the tservers that did not update.
 # Change behavior of  current methods that change config to wait for all tservers to sync (I don't like doing this, would rather leave the current behavoir).
 # Add a new method that allows setting a batch of key/value configs.  This method would also wait for changes to sync across tservers.   Something like {{updateConfiguration(Map<String, String> propsToSet, Set<String> propsToUnset, long timeout, TimeUnit tu)}}.  Of course pass in class instead of 4 params.

I kinda like 3. What other API changes could solve this?

> [UMBRELLA] Remove non-transient data from ZooKeeper
> ---------------------------------------------------
>
>                 Key: ACCUMULO-3842
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-3842
>             Project: Accumulo
>          Issue Type: Improvement
>          Components: client, tserver
>            Reporter: Josh Elser
>             Fix For: 1.8.0
>
>
> Wanted to start brainstorming about this.
> We store a lot of persistent data in ZooKeeper that would better stored in something backed by HDFS. ZooKeeper can be a very convenient place to store persisted data so that it's available to all nodes, but it comes at a price and often must be asynchronously accessed to achieve good performance.
> * Table/Namespace configuration
> * Users/Authorizations
> * Problem reports (maybe?)
> * System configuration overrides (maybe?)
> Some benefits we'd see from this:
> * Loss of ZooKeeper doesn't lose table configuration and users.
> * Greatly reduce zookeeper watchers (assume watchers=50*num_tables*num_tservers)
> * Consistent updates of table constraints and all other table properties
> The last note is the most important one IMO. The number of test issues alone that we've had with constraints not being seen on all servers are bound to affect users.



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