Return-Path: 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 E28F11035E for ; Mon, 28 Apr 2014 19:34:18 +0000 (UTC) Received: (qmail 25953 invoked by uid 500); 28 Apr 2014 19:34:16 -0000 Delivered-To: apmail-accumulo-notifications-archive@accumulo.apache.org Received: (qmail 25907 invoked by uid 500); 28 Apr 2014 19:34:15 -0000 Mailing-List: contact notifications-help@accumulo.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: jira@apache.org Delivered-To: mailing list notifications@accumulo.apache.org Received: (qmail 25894 invoked by uid 99); 28 Apr 2014 19:34:15 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 28 Apr 2014 19:34:15 +0000 Date: Mon, 28 Apr 2014 19:34:15 +0000 (UTC) From: "Josh Elser (JIRA)" To: notifications@accumulo.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Updated] (ACCUMULO-2743) Improve stale-reads with ZooKeeper-backed data 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-2743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated ACCUMULO-2743: --------------------------------- Issue Type: Sub-task (was: Improvement) Parent: ACCUMULO-2589 > Improve stale-reads with ZooKeeper-backed data > ---------------------------------------------- > > Key: ACCUMULO-2743 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2743 > Project: Accumulo > Issue Type: Sub-task > Reporter: Josh Elser > Fix For: 1.7.0 > > > Writing test code against Accumulo, especially via MiniAccumuloCluster, can be extremely frustrating. ZooKeeper is used for managing table configurations, among other things, to allow all tabletservers to be aware of the state of a table. > The problem is that each tabletserver uses a Watcher to see when updates occur, and then it updates an internal cache of these properties. This is a problem even on an instance with a single tserver when setting a table property (configuring an iterator is a good example). The setTableProperty command is implemented via the Master, not a tserver like fetching the table configuration is implemented, which means that you're racing against the Watcher in the tserver. > The cause of this is that test code gets riddled with code like the following: > {code} > String myProperty = tableConfiguration.getProperty("myProperty"); > for (int i = 0; i < retries && null == myProperty; i++) { > myProperty = tableConfiguration.getProperty("myProperty"); > Thread.sleep(some_millis); > } > // Hope that you actually saw the update > Assert.assertNotNull(myProperty) > {code} -- This message was sent by Atlassian JIRA (v6.2#6252)