0

I am trying to copy a blob from a source location to a destination location under lease. I am using a modified version of AutoRenewLease to be able to do this. Here are the steps in my code

  1. Create an empty destination blob if blob doesn't exist
  2. Obtain a regular 30 second lease (which I autorenew) on the blob with leaseId
  3. Use leaseId to create an AccessCondition object
  4. Pass the AccessCondition object to StartCopyFromBlobAsync as destAccessCondition

Actual Result: The remote server returned an error: (412) The lease ID matched, but the specified lease must be an infinite-duration lease.

Is there a way to workaround this issue and copy a blob without an infinite lease.

Yam
  • 293
  • 3
  • 12
  • Is there a reason why you want to acquire the lease on the destination blob? – Gaurav Mantri Nov 25 '15 at 17:54
  • Yes, I would like to prevent concurrent writes to the blob. I preferred to have leases over reacting to 409s unless there is no other way – Yam Nov 25 '15 at 17:56
  • Thanks. 2nd question - Is there a reason you don't want infinite lease on the blob? – Gaurav Mantri Nov 25 '15 at 17:58
  • Yes, if the blob was partially copied and the copy VM crashed, no other VM or process can take a lease on the blob because it was infinitely leased out. I am not sure what other problems will occur with infinite leases but I am worried about recovery – Yam Nov 25 '15 at 18:25

2 Answers2

1

Based on the documentation here, it is not possible to initiate a copy blob operation where destination blob has finite lease.

enter image description here

So if you want to go with lease option, it will have to be an infinite lease on the blob.

Here's one approach I could think of: Because you're already leasing the blob and constantly renewing the lease, my assumption is that you're storing this lease id somewhere (your copy VM could possible crash in those 30 second as well). So what you could do is acquire infinite lease, save the lease id on the blob in some permanent storage.

Then you constantly check the copy status of the destination blob. Once the blob is copied completely, you can simply break the lease on the blob. Now there's a possibility (as you mentioned) that your copy VM could go down. In that case, once the copy VM comes back online you start checking the copy status again. Also the maximum time alloted for copy operation is 2 weeks. If the blob is not copied in 2 weeks, you could simply break the lease on that blob. Please note that you don't need a least id when breaking lease on a blob.

Gaurav Mantri
  • 128,066
  • 12
  • 206
  • 241
0

Thanks for your solution Gaurav. It is very weird that anyone can break a lease. Here is the solution I decided to go with.

Instead of using leases on blobs, I check for Status 409 (HttpStatusCode.Conflict). If 2 concurrent threads write to the same blob, one of them will obtain a 409 conflict. I have placed a wait on this second concurrent thread that got a 409 for a small period of time (since I know the size of the blob to be copied) and check a metadata on the blob (progress = "done"). The earlier thread which is doing the copy will set this metadata once its done copying. I am copying very small blobs so this approach will work for me. If I timeout waiting for the metadata to show up, I fail the second request so user can retry. I am doing this under the presumption that it is better to fail fast and let user retry than wait indefinitely.

Yam
  • 293
  • 3
  • 12