Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hdfs-issues@hadoop.apache.org
Date: Tue, 18 Sep 2012 11:43:07 +1100 (NCT)
From: "Eli Collins (JIRA)" <jira@apache.org>
To: hdfs-issues@hadoop.apache.org
Message-ID: <448370973.90541.1347928987589.JavaMail.jiratomcat@arcas>
Subject: [jira] [Created] (HDFS-3946) Separate client and server uses of
 NN#getAddress
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Eli Collins created HDFS-3946:
---------------------------------

             Summary: Separate client and server uses of NN#getAddress
                 Key: HDFS-3946
                 URL: https://issues.apache.org/jira/browse/HDFS-3946
             Project: Hadoop HDFS
          Issue Type: Improvement
          Components: name-node
    Affects Versions: 2.0.0-alpha
            Reporter: Eli Collins
            Priority: Minor


The use of the various static NN#getAddress methods are hard to follow because they're used by by the NN itself, the DFS client, and NN related services like the fsck and the balancer. They all use fs.getDefaultFS to determine the address, however in the NN case this config has been clobbered with the RPC address rather than use the core-site.xml value. In the other cases it has not. This makes it tedious to figure out things like all the various places the server side RPC addr gets used (eg in HDFS-3932 where it's set to the wildcard). This would be a lot easier to follow if the NN and client uses where separate so we could easily see where the NN is determining it's address (and using the clobbered value) and where the clients are determining it (and using the core-site value).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira