[
https://issues.apache.org/jira/browse/HDFS-12681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16219657#comment-16219657
]
Chris Douglas commented on HDFS-12681:
--------------------------------------
[~andrew.wang] Would it be possible to run v05 and/or v06 through your internal
validation? If an existing client- like MapReduce- distinguishes between the
two types, then it's possible this could be an incompatible change. IIRC, at
least in the MapReduce case, the client should have requested that the
locations be populated, but this is not guaranteed.
v06 makes a change to HDFS, but 1) it changes the semantics of
{{getFileBlockLocations(FileStatus)}} and 2) {{FileSystem}} implementations
running MapReduce jobs may make redundant RPC calls without a similar
short-circuit.
For that reason, I'd rather apply v05. Unless the application applies a highly
selective filter, it should be calling {{FileSystem#listLocatedStatus}} (as
MapReduce does), anyway.
> Fold HdfsLocatedFileStatus into HdfsFileStatus
> ----------------------------------------------
>
> Key: HDFS-12681
> URL: https://issues.apache.org/jira/browse/HDFS-12681
> Project: Hadoop HDFS
> Issue Type: Bug
> Reporter: Chris Douglas
> Priority: Minor
> Attachments: HDFS-12681.00.patch, HDFS-12681.01.patch,
> HDFS-12681.02.patch, HDFS-12681.03.patch, HDFS-12681.04.patch,
> HDFS-12681.05.patch, HDFS-12681.06.patch
>
>
> {{HdfsLocatedFileStatus}} is a subtype of {{HdfsFileStatus}}, but not of
> {{LocatedFileStatus}}. Conversion requires copying common fields and shedding
> unknown data. It would be cleaner and sufficient for {{HdfsFileStatus}} to
> extend {{LocatedFileStatus}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
