[
https://issues.apache.org/jira/browse/HDFS-3946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eli Collins updated HDFS-3946:
------------------------------
Description: The use of the various static NN#getAddress methods are hard
to follow because they're used by by the NN itself, the DFS client, and NN
related services (fsck , balancer, zkfc, etc) and the non-server NN uses (eg
bootstrap standby) . They all use fs.getDefaultFS to determine the address,
however in the NN case this config has been clobbered with the RPC address
rather than use the core-site.xml value. In the other cases it has not. This
makes it tedious to figure out things like all the various places the server
side RPC addr gets used (eg in HDFS-3932 where it's set to the wildcard). This
would be a lot easier to follow if the NN and client uses where separate so we
could easily see where the NN is determining it's address (and using the
clobbered value) and where the clients are determining it (and using the
core-site value). (was: The use of the various static NN#getAddress methods
are hard to follow because they're used by by the NN itself, the DFS client,
and NN related services like the fsck and the balancer. They all use
fs.getDefaultFS to determine the address, however in the NN case this config
has been clobbered with the RPC address rather than use the core-site.xml
value. In the other cases it has not. This makes it tedious to figure out
things like all the various places the server side RPC addr gets used (eg in
HDFS-3932 where it's set to the wildcard). This would be a lot easier to follow
if the NN and client uses where separate so we could easily see where the NN is
determining it's address (and using the clobbered value) and where the clients
are determining it (and using the core-site value).)
> Separate client and server uses of NN#getAddress
> ------------------------------------------------
>
> Key: HDFS-3946
> URL: https://issues.apache.org/jira/browse/HDFS-3946
> Project: Hadoop HDFS
> Issue Type: Improvement
> Components: name-node
> Affects Versions: 2.0.0-alpha
> Reporter: Eli Collins
> Priority: Minor
>
> The use of the various static NN#getAddress methods are hard to follow
> because they're used by by the NN itself, the DFS client, and NN related
> services (fsck , balancer, zkfc, etc) and the non-server NN uses (eg
> bootstrap standby) . They all use fs.getDefaultFS to determine the address,
> however in the NN case this config has been clobbered with the RPC address
> rather than use the core-site.xml value. In the other cases it has not. This
> makes it tedious to figure out things like all the various places the server
> side RPC addr gets used (eg in HDFS-3932 where it's set to the wildcard).
> This would be a lot easier to follow if the NN and client uses where separate
> so we could easily see where the NN is determining it's address (and using
> the clobbered value) and where the clients are determining it (and using the
> core-site value).
--
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
