Mailing-List: contact core-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: core-dev@hadoop.apache.org
Message-ID: <1709609956.1243005166718.JavaMail.jira@brutus>
Date: Fri, 22 May 2009 08:12:46 -0700 (PDT)
From: "Todd Lipcon (JIRA)" <jira@apache.org>
To: core-dev@hadoop.apache.org
Subject: [jira] Commented: (HADOOP-5891) If dfs.http.address is default,
 SecondaryNameNode can't find NameNode
In-Reply-To: <814131517.1242953985647.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HADOOP-5891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12712132#action_12712132 ] 

Todd Lipcon commented on HADOOP-5891:
-------------------------------------

Steve: I agree that service location can be improved across the board. However, I don't think it's necessarily a good idea to overload the NameNode as a service name daemon. Personally, I'd prefer to use something like ZooKeeper here. Obviously there needs to be at least one host that is in a "well-known" location, which could be configured by default as a "hadoop-zk" hostname which has multiple A records pointing to all of the ZK nodes.

Anyway, I agree that we should work towards the ideal goal, but I'd like to have that discussion in a new JIRA. This one is a very simple fix whereas that one could be pretty significant.

> If dfs.http.address is default, SecondaryNameNode can't find NameNode
> ---------------------------------------------------------------------
>
>                 Key: HADOOP-5891
>                 URL: https://issues.apache.org/jira/browse/HADOOP-5891
>             Project: Hadoop Core
>          Issue Type: Bug
>          Components: dfs
>            Reporter: Todd Lipcon
>            Assignee: Todd Lipcon
>         Attachments: hadoop-5891.txt
>
>
> As detailed in this blog post:
> http://www.cloudera.com/blog/2009/02/10/multi-host-secondarynamenode-configuration/
> if dfs.http.address is not configured, and the 2NN is a different machine from the NN, the 2NN fails to connect.
> In SecondaryNameNode.getInfoServer, the 2NN should notice a "0.0.0.0" dfs.http.address and, in that case, pull the hostname out of fs.default.name. This would fix the default configuration to work properly for most users.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.