[
https://issues.apache.org/jira/browse/HDFS-12459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16242353#comment-16242353
]
Rushabh S Shah commented on HDFS-12459:
---------------------------------------
bq. I have removed those changes. I am OK to add them back if you think this
is better. Please let me know.
I definitely don't want to see 2 step process.
For documentation changes, I don't know what is the right answer.
IMO, it should be GET_BLOCK_LOCATIONS and since it confirms to
{{fileSystem#getFileBlockLocations}}, the end user should not care about the
implementation. That way it will be consistent with the actual implementation
also.
Hope this helps.
> Fix revert: Add new op GETFILEBLOCKLOCATIONS to WebHDFS REST API
> ----------------------------------------------------------------
>
> Key: HDFS-12459
> URL: https://issues.apache.org/jira/browse/HDFS-12459
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: webhdfs
> Reporter: Weiwei Yang
> Assignee: Weiwei Yang
> Attachments: HDFS-12459.001.patch, HDFS-12459.002.patch,
> HDFS-12459.003.patch, HDFS-12459.004.patch, HDFS-12459.005.patch
>
>
> HDFS-11156 was reverted because the implementation was non optimal, based on
> the suggestion from [~shahrs87], we should avoid creating a dfs client to get
> block locations because that create extra RPC call. Instead we should use
> {{NamenodeProtocols#getBlockLocations}} then covert {{LocatedBlocks}} to
> {{BlockLocation[]}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
