[ https://issues.apache.org/jira/browse/HDFS-9001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14745770#comment-14745770 ]
Aaron T. Myers commented on HDFS-9001: -------------------------------------- Hey Daniel, I think this makes sense, thanks very much for the lucid explanation. I think the really correct thing to do (ignoring backward compatibility concerns) would be to make fs.defaultFS a client-side config only. It's only for historical reasons that it's not, in that I believe in the NN we fall back to having the NN bind to that as its RPC address if no {{rpc-address}} address is actually configured. We can only change that behavior in a major version, though, so I don't think we should do that here. I think the way to go is to fix this JIRA as you propose, and then file a separate, backward-incompatible JIRA to change the NN (and all admin commands) to no longer look at fs.defaultFS at all. We'd then only commit that to trunk (and not branch-2) so it'll show up in Hadoop 3.0. Does that make sense? > DFSUtil.getNsServiceRpcUris() can return too many entries in a non-HA, > non-federated cluster > -------------------------------------------------------------------------------------------- > > Key: HDFS-9001 > URL: https://issues.apache.org/jira/browse/HDFS-9001 > Project: Hadoop HDFS > Issue Type: Bug > Components: HDFS > Affects Versions: 2.6.0, 2.7.0, 2.7.1 > Reporter: Daniel Templeton > Assignee: Daniel Templeton > > If defaultFS differs from rpc-address, then DFSUtil.getNsServiceRpcUris() > will return two entries: one for the [service] RPC address and one for the > default FS. This behavior violates the expected behavior stated in the > JavaDoc header. -- This message was sent by Atlassian JIRA (v6.3.4#6332)