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

Zhe Zhang commented on HDFS-8499:
---------------------------------

Many thanks for Yi and Vinay for the reviews!

bq. In BlockInfoUnderConstruction, we can implement 
addStorage/removeStorage/numNodes/replaceBlock, no need to push them to 
subclass.
Good point, subclass only need to implement {{convertToCompleteBlock}} 
separately.

bq. In BlockInfo, convertToBlockUnderConstruction should be abstract, and 
continuous/striped block implement it.
Agreed. Will address in the next rev.

bq. I think these methods you can directly move to BlockInfo itself as non of 
these methods are having any difference in subclasses, at least as of now. 
Actually {{BlockInfoStriped}} will implement 
addStorage/removeStorage/numNodes/replaceBlock differently than 
{{BlockInfoContiguous}}. So as shown below, {{BlockInfoStriped}}, 
{{BlockInfoContiguous}}, and {{BlockInfoUC}} each has a different 
{{addStorage}} logic. In particular, {{BlockInfoUC}} just converts itself to a 
complete block -- this conversion has different implementations in 
{{BlockInfoUCStriped}} and {{BlockInfoUCContiguous}} -- and calls the 
corresponding {{addStorage}}.

The {{convertToCompleteBlock()}} logic is necessary because 
{{BlockInfoUCStriped}} no longer subclasses {{BlockStriped}} and we needs an 
explicit conversion to the right type of complete block.

{code}
                BlockInfo (abstract)
               /     |   \
BlockInfoStriped     |    BlockInfoContiguous
#addStorage_s        |    #addStorage_c
                     |          
               BlockInfoUC(abstract)
               #addStorage_uc = 
                 convertToCompleteBlock().addStorage
                  /            \      
BlockInfoStripedUC          BlockInfoContiguousUC
#convertToCompleteBlock_s   #convertToCompleteBlock_c
{code}

Right now the striped classes are not in, so yes, we can put these methods in 
the superclass and move them later. But I guess it's easier to put them in the 
right subclasses so we can catch incoming changes during the merge process?

> Merge BlockInfoUnderConstruction into trunk
> -------------------------------------------
>
>                 Key: HDFS-8499
>                 URL: https://issues.apache.org/jira/browse/HDFS-8499
>             Project: Hadoop HDFS
>          Issue Type: Sub-task
>          Components: namenode
>    Affects Versions: 2.7.0
>            Reporter: Zhe Zhang
>            Assignee: Zhe Zhang
>         Attachments: HDFS-8499.00.patch
>
>
> In HDFS-7285 branch, the {{BlockInfoUnderConstruction}} interface provides a 
> common abstraction for striped and contiguous UC blocks. This JIRA aims to 
> merge it to trunk.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to