hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron T. Myers (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-3144) Refactor DatanodeID#getName by use
Date Sun, 01 Apr 2012 20:40:27 GMT

    [ https://issues.apache.org/jira/browse/HDFS-3144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13243846#comment-13243846

Aaron T. Myers commented on HDFS-3144:

This is great cleanup, Eli. Thanks a lot for doing it. A few small comments. +1 once these
and the findbugs warning is explained or fixed.

# In UnregisteredNodeException, I wonder if you shouldn't just be using toString instead of
getXferAdder? Looks to me like it's going to be used just as a log message.
# Likewise seems like we should just use toString() in InvalidateBlocks#dump.
# To hopefully prevent these misuses of DatanodeID methods, maybe add a comment at the top
of DatanodeID explaining clearly when each should be used? e.g. "use toString() in log messages,
use dataXferPort for..., etc."
> Refactor DatanodeID#getName by use
> ----------------------------------
>                 Key: HDFS-3144
>                 URL: https://issues.apache.org/jira/browse/HDFS-3144
>             Project: Hadoop HDFS
>          Issue Type: Improvement
>          Components: data-node
>            Reporter: Eli Collins
>            Assignee: Eli Collins
>         Attachments: hdfs-3144.txt, hdfs-3144.txt, hdfs-3144.txt
> DatanodeID#getName, which returns a string containing the IP:xferPort of a Datanode,
is used in a variety of contexts:
> # Putting the ID in a log message
> # Connecting to the DN for data transfer
> # Getting a string to use as a key (eg for comparison)
> # Using as a hostname, eg for excludes/includes, topology files
> Same for DatanodeID#getHost, which returns just the IP part, and sometimes we use it
as a key, sometimes we tack on the IPC port, etc.
> Let's have a method for each use, eg toString can be used for #1, a new method (eg getDataXferAddr)
for #2, a new method (eg getKey) for #3, new method (eg getHostID) for #4, etc. Aside from
the code being more clear, we can change the value for particular uses, eg we can change the
format in a log message without changing the address used that clients connect to the DN,
or modify the address used for data transfer without changing the other uses.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message