hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eli Collins (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HDFS-3946) Separate client and server uses of NN#getAddress
Date Tue, 18 Sep 2012 00:45:07 GMT

     [ 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

Mime
View raw message