accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Havanki (JIRA)" <j...@apache.org>
Subject [jira] [Created] (ACCUMULO-2876) Unexpected looping from HdfsZooInstance.getInstanceID()
Date Mon, 09 Jun 2014 18:21:02 GMT
Bill Havanki created ACCUMULO-2876:
--------------------------------------

             Summary: 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)

Mime
View raw message