[
https://issues.apache.org/jira/browse/HADOOP-12508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14974678#comment-14974678
]
Chris Nauroth commented on HADOOP-12508:
----------------------------------------
Thank you for the further details, [~gouravk].
It sounds like the root cause here is likely a difference in the lease
semantics of WASB compared to HDFS. In HDFS, a delete operation succeeds
despite another concurrent client holding a lease on that path. In WASB, it
fails due to the lease enforcement of the backing Azure Storage.
Would it be a potential improvement to break the lease explicitly? The
downside of the current patch is that a client calling delete on a path with a
lease held and the leasing process still alive will suffer up to 60 seconds
additional latency. If the lease was broken explicitly, then you could send a
shorter x-ms-lease-break-period to avoid that latency.
> delete fails with exception when lease is held on blob
> ------------------------------------------------------
>
> Key: HADOOP-12508
> URL: https://issues.apache.org/jira/browse/HADOOP-12508
> Project: Hadoop Common
> Issue Type: Bug
> Reporter: Gaurav Kanade
> Assignee: Gaurav Kanade
> Priority: Blocker
> Attachments: HADOOP-12508.01.patch, HADOOP-12508.02.patch
>
>
> The delete function as implemented by AzureNativeFileSystem store attempts
> delete without a lease. In most cases this works but in the case of a
> dangling lease resulting out of say a process killed and leaving a lease
> dangling for a small period a delete attempted during this period simply
> crashes. This fix addresses the situation by re-attempting the delete after a
> lease acqusition in this case
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
