[
https://issues.apache.org/jira/browse/HDFS-10636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15429061#comment-15429061
]
Lei (Eddy) Xu edited comment on HDFS-10636 at 8/19/16 11:46 PM:
----------------------------------------------------------------
bq. If not, are there existing cases where vendors might be using
FinalizedReplica for non-File backed data?
Yea. I know vendors who have already implemented similar solutions based on
{{FinalizedReplica}}, because {{ProvidedReplica}} did not exist back to the
days. But I think it might be OK for them if this patch did not break their
code.
Another option might be that, "Finalized" looks like a state in the pipeline
state machine, instead of a "Location" where the replica is stored, IMO. Have
you considered about making {{LocalReplica}} and {{ProvidedReplica}} being
subclasses of {{FinalizedReplica}}? So that for the pipeline state machine part
of code, all the existing code can re-use the same {{FinalizedReplica}} as what
it is today. Would love to hear your thoughts about it.
bq. Having a good test coverage seems a cleaner way to solve this.
Agree. That would be a nice thing to do.
was (Author: eddyxu):
bq. If not, are there existing cases where vendors might be using
FinalizedReplica for non-File backed data?
Yea. I know vendors who have already implemented similar solutions based on
{{FinalizedReplica}}, because {{ProvidedReplica}} did not exist back to the
days. But I think it might be OK for them if this patch did not break the
their code.
Another option might be that, "Finalized" looks like a state in the pipeline
state machine, instead of a "Location" where the replica is stored, IMO. Have
you considered about making {{LocalReplica}} and {{ProvidedReplica}} being
subclasses of {{FinalizedReplica}}? So that for the pipeline state machine part
of code, all the existing code can re-use the same {{FinalizedReplica}} as what
it is today. Would love to hear your thoughts about it.
bq. Having a good test coverage seems a cleaner way to solve this.
Agree. That would be a nice thing to do.
> 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
