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

Ayush Saxena commented on HDFS-14440:
-------------------------------------

Thanx [~elgoiri] I have uploaded the patch.
{quote}Keep in mind that the sequential invoke relies on the idea that in most 
case, the files will be in the first location. 
{quote}
If the file exists. Then the actual write won't happen, that is we shall land 
up getting exception from the namenode. The case where write happens shall be 
when file isn't present in neither of the destinations, for which all 
destinations shall be checked, then only conclusion can be reached.(This we can 
do it in parallel)

And in general we should aim to optimize the working flow, as compared to the 
failure case.

> RBF: Optimize the file write process in case of multiple destinations.
> ----------------------------------------------------------------------
>
>                 Key: HDFS-14440
>                 URL: https://issues.apache.org/jira/browse/HDFS-14440
>             Project: Hadoop HDFS
>          Issue Type: Sub-task
>            Reporter: Ayush Saxena
>            Assignee: Ayush Saxena
>            Priority: Major
>         Attachments: HDFS-14440-HDFS-13891-01.patch
>
>
> In case of multiple destinations, We need to check if the file already exists 
> in one of the subclusters for which we use the existing getBlockLocation() 
> API which is by default a sequential Call,
> In an ideal scenario where the file needs to be created each subcluster shall 
> be checked sequentially, this can be done concurrently to save time.
> In another case where the file is found and if the last block is null, we 
> need to do getFileInfo to all the locations to get the location where the 
> file exists. This also can be prevented by use of ConcurrentCall since we 
> shall be having the remoteLocation to where the getBlockLocation returned a 
> non null entry.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to