Mailing-List: contact notifications-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jira@apache.org
Date: Mon, 9 Jun 2014 21:05:01 +0000 (UTC)
From: "Bill Havanki (JIRA)" <jira@apache.org>
To: notifications@accumulo.apache.org
Message-ID: <JIRA.12720162.1402338026855.97273.1402347901495@arcas>
In-Reply-To: <JIRA.12720162.1402338026855@arcas>
References: <JIRA.12720162.1402338026855@arcas>
Subject: [jira] [Updated] (ACCUMULO-2876) Unexpected looping from
 HdfsZooInstance.getInstanceID()
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/ACCUMULO-2876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bill Havanki updated ACCUMULO-2876:
-----------------------------------

    Resolution: Fixed
        Status: Resolved  (was: Patch Available)

> Unexpected looping from HdfsZooInstance.getInstanceID()
> -------------------------------------------------------
>
>                 Key: ACCUMULO-2876
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-2876
>             Project: Accumulo
>          Issue Type: Improvement
>          Components: client
>    Affects Versions: 1.6.0
>            Reporter: Bill Havanki
>            Assignee: Bill Havanki
>            Priority: Minor
>
> While working ACCUMULO-2615, I encountered a weird looping behavior rooted at {{HdfsZooInstance.getInstanceID()}} that seems to accidentally avoid a stack overflow. I'm a bit blocked at the moment on -2615 since my work exposed the loop.
> Here's a summary of the loop. The unit test {{SystemCredentialsTest}} in the tserver module exercises it.
> * Start at {{HdfsZooInstance.getInstanceID()}}, which calls to an internal {{_getInstanceID()}} the first time.
> * A volume manager is needed to find the instance ID in HDFS, so {{VolumeManagerImpl.get()}} is called.
> * That call needs the "system" configuration, so a call to {{ServerConfiguration.getSystemConfiguration()}} is made, passing the {{HdfsZooInstance}} object.
> * The system configuration is a {{ZooConfiguration}} object, and that is created from {{ZooConfiguration.getInstance()}}.
> * That factory method creates a {{ZooConfiguration}} object, saved as a static field. The code then tries to get the instance ID for the passed-in instance, which is the {{HdfsZooInstance}} object. So we're back at the top of the loop.
> In the last step of the second iteration of the loop, the factory method sees that the static field for the singleton instance of {{ZooConfiguration}} was set in the first iteration, so it returns it and doesn't look for the instance ID. That stops the looping and the call stack unwinds.
> (My refactoring work has trouble with this because it gets rid of the single static field in favor of a map of objects keyed by instance ID.)
> This loop indicates a mutual dependency between configurations, the volume manager, and {{HdfsZooInstance}} that should be resolved.


--
This message was sent by Atlassian JIRA
(v6.2#6252)