[
https://issues.apache.org/jira/browse/HDFS-5055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13731555#comment-13731555
]
Aaron T. Myers commented on HDFS-5055:
--------------------------------------
bq. Since the config is defined/clearly not wildcarded, it shouldn't be
resorting to this behavior (e.g., wildly unpredictable).
I'd be fine with changing it so that we fall back to the behavior implemented
in HDFS-3404 only in the event that the wildcard address is configured. That
seems like a pretty simple fix that would address this issue, right?
bq. Given that this is a blocker, we need to fix this ASAP.
I'm really not sure that this should be considered a blocker. Yes, it's a
regression from branch-1, but I suspect it will affect a very small subset of
users.
bq. Aaron T. Myers do you have bandwidth to fix this? Alternatively we can
revert this change and add it back in another dot release?
I don't really have bandwidth to work on this right now, though I'm certainly
interested in implementing HDFS-3405 at some point down the road. I'm not going
to try to stop you from reverting it, but if you do I suspect you will be
breaking a lot more users than you will be fixing.
> nn->2nn ignores dfs.namenode.secondary.http-address
> ---------------------------------------------------
>
> Key: HDFS-5055
> URL: https://issues.apache.org/jira/browse/HDFS-5055
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: namenode
> Affects Versions: 2.1.0-beta
> Reporter: Allen Wittenauer
> Priority: Blocker
>
> The primary namenode attempts to connect back to (incoming hostname):port
> regardless of how dfs.namenode.secondary.http-address is configured.
--
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
