[
https://issues.apache.org/jira/browse/HDFS-4320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mostafa Elhemali updated HDFS-4320:
-----------------------------------
Attachment: HDFS-4320.branch-1.2.patch
I had a conversation with Suresh and he pointed out that I misunderstood trunk
code and my patch for trunk doesn't make sense - we already have
dfs.namenode.rpc-address that can override fs.default.name in trunk, so it
isn't a problem there.
Attached a new patch just for branch-1 that in-spirit ports this configuration
key dfs.namenode.rpc-address, which if present will override fs.default.name
for namenode/datanode to find out what the namenode address is in the cluster.
> NameNode tries to get its address by looking at fs.default.name instead of
> its own config keys
> ----------------------------------------------------------------------------------------------
>
> Key: HDFS-4320
> URL: https://issues.apache.org/jira/browse/HDFS-4320
> Project: Hadoop HDFS
> Issue Type: Bug
> Affects Versions: 1.1.0
> Reporter: Mostafa Elhemali
> Attachments: HDFS-4320.branch-1.2.patch, HDFS-4320.patch,
> HDFS-4320.trunk.2.patch, HDFS-4320.trunk.patch
>
>
> When NameNode starts up, it tries to find out its address by looking at the
> fs.default.name configuration key instead of using its own keys (namely
> dfs.namenode.servicerpc-address). This breaks scenarios where we try to
> configure a Hadoop cluster that uses a different default file system than
> DFS, but still try to prop up namenode and datanode services as a secondary
> file system.
--
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
