hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Todd Lipcon (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-2181) Seperate HDFS wire protocol data types
Date Tue, 04 Oct 2011 17:51:35 GMT

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

Todd Lipcon commented on HDFS-2181:
-----------------------------------

Thanks for the thorough explanation. The general architecture makes sense. It will be a bit
of a pain to maintain, I think, but the benefits are probably worth it.

A few general comments:
- Can we prefix all of the classes in protocolR23Compatible with the string "R23"? So we have
"R23Block" as the wire type and "Block" as the internal type? Or "R23WBlock" to stand for
R23 Writable Block, perhaps? My thinking is that it will make the translator code easier to
read because we don't need to fully qualify all of the wire types with the really long package
name. It may also help in debugging since the short class name will differ. This is also helpful
when developers use autocomplete in the IDE - we don't want to accidentally import the wire
types into internal code.

- Do we really need to duplicate the javadoc "The specification of this method matches that
of ..." for every method in the R23 protocols? Just seems like a lot of boilerplate that will
cause javadoc warnings later if we add arguments to existing methods in the non-wire protocol
interface.

----

A few nits:


- Need an extra ". " in this concatenation:
{code}
+    throw new IOException("Namenode Serverside implements "
+        + ClientNamenodeProtocol.class
+        + "The following requested protocol is unknown: " + protocol);
{code}

----

- There are a few spots where methods have arguments called {{arg0}}, {{arg1}}, etc.
- The constants GET_STATS_CAPACITY_IDX, etc, should probably be part of the generic protocol,
not the R23 protocol, since the FSNamesystem method itself returns the array of longs. Perhaps
we can just file a follow-up JIRA to replace this with some kind of FileSystemStats class
instead of the somewhat ugly array?

                
> Seperate HDFS wire protocol data types
> --------------------------------------
>
>                 Key: HDFS-2181
>                 URL: https://issues.apache.org/jira/browse/HDFS-2181
>             Project: Hadoop HDFS
>          Issue Type: Improvement
>            Reporter: Sanjay Radia
>            Assignee: Sanjay Radia
>         Attachments: separateDataType1.patch, separateDataType10.patch, separateDataType11.patch,
separateDataType12.patch, separateDataType13.patch, separateDataType14.patch, separateDataType16.patch,
separateDataType2.patch, separateDataType6.patch, separateDataType7.patch, separateDataType8.patch,
separateDataType9.patch
>
>


--
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

        

Mime
View raw message