[
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.trunk.2.patch
OK I just realized the error of my ways: the original patch I uploaded was
incorrect, since it was trying to overload the dfs.namenode.servicerpc-address
configuration which is just meant for providing a second endpoint for services
as opposed to clients of NameNode.
I have a second proposed fix for this problem: a new configuration key
dfs.namenode.address that specifies the namenode's address if present. If it's
absent, we fallback on today's fs.default.name logic. Would that work?
> 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.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
