[
https://issues.apache.org/jira/browse/HADOOP-12484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14968091#comment-14968091
]
Chris Nauroth commented on HADOOP-12484:
----------------------------------------
{code}
if (errorCode.equals("BlobNotFound")) {
// The rename already finished, so do nothing.
;
} else {
throw e;
}
{code}
This part is triggering a Checkstyle warning:
{code}
./hadoop-tools/hadoop-azure/src/main/java/org/apache/hadoop/fs/azure/NativeAzureFileSystem.java:580:9:
Empty statement.
{code}
We can clean that up by changing to:
{code}
// If the rename already finished, do nothing.
if (!errorCode.equals("BlobNotFound")) {
throw e;
}
{code}
I realize there are existing instances of empty statements like this in the
{{NativeAzureFileSystem}} class, but let's avoid introducing new instances.
The mvninstall failure appears to be a side effect of something in the bats
testing of the bash scripts. It's unrelated to this patch. Since you need to
upload one more patch revision to address the Checkstyle warning, let's do one
more test run and see if it happens again. If it does, then I'll follow up.
The license check warning is caused by a test copying a file to a location that
it shouldn't, which is then covered by the license check. I'll follow up
separately on that.
> Single File Rename Throws Incorrectly In Potential Race Condition Scenarios
> ---------------------------------------------------------------------------
>
> Key: HADOOP-12484
> URL: https://issues.apache.org/jira/browse/HADOOP-12484
> Project: Hadoop Common
> Issue Type: Bug
> Components: tools
> Reporter: Gaurav Kanade
> Assignee: Gaurav Kanade
> Attachments: HADOOP-12484.01.patch, HADOOP-12484.02.patch,
> HADOOP-12484.03.patch, HADOOP-12484.04.patch
>
>
> FinishSingleFileRename function - in the case where src and dst both exist
> gets a lease on src blob to block write access and then deletes the file.
> However in the time between checking existence of source file and acquiring
> lease the file may be deleted by another process (race condition). Presently
> the function simply throws in this scenario. In this case the function should
> treat this as a case where rename is complete; i.e. catch the exception and
> if this is the cause exit gracefully with the result that the rename is
> complete
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
