locked
A problem related to lease blob RRS feed

  • Question

  • Hi All,

    The Lease Blob operation establishes and manages a one-minute lock on a blob for write operations, as written in http://msdn.microsoft.com/en-us/library/ee691972.aspx . So after acquiring lease on a blob, I have to wait for one minute to acquire lease again on the same blob and blob lease status should be 'Locked' for one minute.

    I am able to acquire lease on the same blob after one minute, which is true, but when I see blob's property I get blob's lease status 'Locked' even after 30 minutes. The x-ms-request-id or my request is '49c3b6c2-cd9b-49d3-8489-7014e6cbfaf8'.

     

    Same thing I did in development storage. But result was something different. After acquiring lease on a blob, neither I m able to acquire lease on the same blob nor blob's lease status is changed to 'Unlocked' even after 2 hours.

    Can anyone let me know why this is happening?


    Amit Jain

    http://www.cerebrata.com/

    Tuesday, August 17, 2010 1:34 PM

All replies

  • Are you using development storage?  If I recall correctly, there's a bug in development storage that doesn't expire old leases.  It works properly with true cloud storage.
    Tuesday, August 17, 2010 6:12 PM
  • Hi Steve,

    It happens on the cloud storage as well. So we acquire a lease on the blob. Leave that idle for a couple of minutes and then try to get the list of the blobs again. The blob lease status comes as locked in the response from the storage service. You can acquire a new lease however. The x-ms-request-id included above is for cloud storage only.

    Thanks

    Gaurav

    Tuesday, August 17, 2010 6:17 PM
  • Sorry, read the question too quickly.  Let me flag this for the storage team.
    Tuesday, August 17, 2010 6:21 PM
  • Thanks for finding and reporting this.  

     

    It is a bug, where after the lease is held and has expired, we are incorrectly returning that the blob is still locked, when it actually is not locked.   That is why you are able to acquire the lease again, since it isn’t locked.  We will get this fixed a future service update, and post back here when it is done.

     

     

    Thanks,

    Brad

    Tuesday, August 17, 2010 7:24 PM
  • Hi Brad, 

    We are seeing the same issue that a lease is incorrectly set when viewing a blob in cloud storage explorer.
    Have microsoft fixed this issue with the current sdk 1.5?

     

    Regards Niclas 

    Thursday, September 29, 2011 8:51 AM
  • We have not fixed this for listing operation which the storage explorer may be using. We expect to fix this so that the service returns the appropriate lease information by end of this year.

    Sorry for the inconvenience.

    Jai

    Thursday, September 29, 2011 4:57 PM
  • So, does this bug mean that we should not try to use leases to manage concurrency for tasks running in worker roles?

    http://blog.smarx.com/posts/managing-concurrency-in-windows-azure-with-leases

    In my cloud application I have worker role instance 0 and instance 1, that try to do a some work. In my scenario, I have TaskA that can only be run by one worker instance at a time, i.e. multiple worker instances are not allowed to execute TaskA in parallel.

    Are you saying that lease expiration works as expected BUT it simply shows up wrong when doing a listing?

    Monday, October 10, 2011 6:41 PM
  • Hi Brad, Jai,

    Is there any work around for this?

    Thanks, Seetha

    Tuesday, October 11, 2011 10:23 AM
  •  >>So, does this bug mean that we should not try to use leases to manage concurrency for tasks running in worker roles?

    The lease does expire and it is only the status which is incorrect when you list blobs in a container. When you use a lease you most likely will do this on a single blob. You can use the Get Blob Properties REST API (i.e. HEAD request) or FetchAttributes in Client library which issues HEAD request to get the lease status and other properties.

    NOTE: It is only when you list that it does not fetch the correct lease status.

     

      >> Is there any work around for this

    You can get individual blob properties as mentioned above.

     

    Thanks,

    jai

    • Proposed as answer by DevilDog74 Wednesday, November 9, 2011 7:19 PM
    Tuesday, October 11, 2011 1:00 PM
  • Ok, so, it is true that when using development storage I can use BlobRequest.GetMetadata to determine if the blob is "really" leased.

    However, what I really need to do... is execute BlobRequest.Lease(myUri, 90, LeaseAction.Acquire, null) but when I execute the call, error status code 409 is returned.  i.e. conflict, because developmentstorage still thinks the blob is leased.

    Is this also a bug in development storage?

    If I get into this state what should I do?  Delete my blob and start over?  Use a real storage account?

    Wednesday, November 9, 2011 9:55 PM
  • -- Ok, so, it is true that when using development storage I can use BlobRequest.GetMetadata to determine if the blob is "really" leased.

    With distributed systems it is nearly always better to use an optimistic model of "act then handle failure" than a pessimistic model of "test then act." The reason is that the conditions that lead to success in the test may change before a subsequent act is performed. The implication of this is that you should almost never test whether a blob is "really" leased, you should just try to lease the blob and then handle the failure if it is already leased. After all, the lease operation could fail for other reasons than the blob is already leased.

    Thursday, November 10, 2011 2:43 AM
    Answerer
  • Neil, you're right, but he's trying to work around a bug in the storage emulator where this functionality isn't actually working.

     

    DevilDog74, my advice would be to use a real storage account.

    • Proposed as answer by DevilDog74 Thursday, November 10, 2011 5:20 PM
    Thursday, November 10, 2011 2:49 AM
  • -- DevilDog74, my advice would be to use a real storage account.

    This is nearly always the first thing I try whenever I have a problem with the storage emulator. It is too hard to remember the edge cases where it doesn't work.

    Thursday, November 10, 2011 3:26 AM
    Answerer