[
https://issues.apache.org/jira/browse/HDFS-10636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15427349#comment-15427349
]
Lei (Eddy) Xu commented on HDFS-10636:
--------------------------------------
Hi, [~virajith]
Thanks a lot for update the patch and address the comments. And appreciate
much for taking our comments into consideration.
bq. The other way to deal with this would be to add setDir to ReplicaInfo but
to avoid File as a parameter.
What I am worried about is that, this constraint might not hold true for wider
audience. E.g., If you implement recovery logic in Azure or S3, the input
should not be a File based replica.
bq.it should take in an URI. Which do you think is better?
Maybe using {{StorageLocation}} as input? There was some efforts to abstract
{{File}} to {{StorageLocation}}.
bq. {{FinalizedReplica}} in the current type hierarchy, is a LocalReplica.
Would that still be the case for Azure? I have saw a few cases that it is not a
file-based solution. Also, {{FinalizedReplica}} should be the most common class
in the {{ReplicaInfo}} hierarchy, so I guess many vendors might expect using
{{FinalizedReplica}} to directly represent the block data.
bq. The way I was thinking about it was that the state of ReplicaInfo should be
known using ReplicaInfo::getState(), and not using the type system.
I don't have strong option against the solution proposed here. The concerns of
getting rid of type system and using {int} / {enum} to indicate the class type
might make the other developer difficult to have good confident to write
correct code, because like dynamic language as python/ruby, the bugs become
hard to spot during compile time. If we can come up a good test coverage, the
concern can be overcome to some extend.
Thanks.
> Modify ReplicaInfo to remove the assumption that replica metadata and data
> are stored in java.io.File.
> ------------------------------------------------------------------------------------------------------
>
> Key: HDFS-10636
> URL: https://issues.apache.org/jira/browse/HDFS-10636
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: datanode, fs
> Reporter: Virajith Jalaparti
> Assignee: Virajith Jalaparti
> Attachments: HDFS-10636.001.patch, HDFS-10636.002.patch,
> HDFS-10636.003.patch, HDFS-10636.004.patch, HDFS-10636.005.patch
>
>
> Replace java.io.File related APIs from {{ReplicaInfo}}, and enable the
> definition of new {{ReplicaInfo}} sub-classes whose metadata and data can be
> present on external storages (HDFS-9806).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
