Unexpected NotSupportedException Error - appeared while putblock on Aug 12 2012 : Are such errors common with Azure storage & what's recommendation

Answered Unexpected NotSupportedException Error - appeared while putblock on Aug 12 2012 : Are such errors common with Azure storage & what's recommendation

  • Sunday, August 12, 2012 5:00 PM
     
     

    Hello,

    I have a services which is uploading blobs for our business purposes. Today I notice that below was an Error while putblock. The service has been running for a few weeks now & processed more than 100 blobs, but never saw the below. This appeared today, 8/12/2012 11:20 AM UTC

    So can someone shed light on why the below could appear & what is recommendation in such situations.

    Thanks.

    ---------------------------------------------------

    Unhandled Exception: System.NotSupportedException: The stream does not support c
    oncurrent IO read or write operations.
       at Microsoft.WindowsAzure.StorageClient.Tasks.Task`1.get_Result()
       at Microsoft.WindowsAzure.StorageClient.Tasks.Task`1.ExecuteAndWait()
       at Microsoft.WindowsAzure.StorageClient.TaskImplHelper.ExecuteImplWithRetry(F
    unc`1 impl, RetryPolicy policy)
       at Microsoft.WindowsAzure.StorageClient.CloudBlockBlob.PutBlock(String blockI
    d, Stream blockData, String contentMD5, BlobRequestOptions options)
       at Microsoft.WindowsAzure.StorageClient.CloudBlockBlob.PutBlock(String blockI
    d, Stream blockData, String contentMD5)


    Manu



    • Edited by ManuY Sunday, August 12, 2012 5:04 PM
    •  

All Replies

  • Sunday, August 12, 2012 5:26 PM
     
     Proposed

    Hi ManuY,

    Is it possible for you to share some code (upload part)?

    I recommend you checking out this a similar thread here.

    It could be that there is more than one process trying to access the stream at one time (as CloudBlobClient class is not thread safe). Or, less likely, it could be that you are creating too many requests and possibly throttling your storage account.

    Hope this helps!


    Best Regards,
    Carlos Sardo

    • Proposed As Answer by Carlos Sardo Sunday, August 12, 2012 8:18 PM
    •  
  • Sunday, August 12, 2012 7:29 PM
     
     

    Thanks for the response.

    I was sharing the same container between threads, and that could potentially have been the problem. In my previous tests this had not come up. But I am now creating separate container instance for each thread. Hope that will solve the problem. Will share updates tomorrow.

    Another question, "you are creating too many requests and possibly throttling your storage account." : Are there any limits we should be aware? We are currently performing 12 threads upload & download on each vm.. and also as need be we will increase number of vms. So it will imp for us to understand if there are any upper limits on request block blob requests.

    Thanks.


    Manu

  • Sunday, August 12, 2012 8:22 PM
     
     Answered

    Another question, "you are creating too many requests and possibly throttling your storage account." : Are there any limits we should be aware? We are currently performing 12 threads upload & download on each vm.. and also as need be we will increase number of vms. So it will imp for us to understand if there are any upper limits on request block blob requests.

    Thanks.


    Manu

    Hi ManuY,

    Yes, there are limits:

    The following are the scalability targets for a single storage account:

    • Capacity – Up to 100 TBs
    • Transactions – Up to 5,000 entities/messages/blobs per second
    • Bandwidth – Up to 3 gigabits per second

    I do strongly recommend you reading this blog post on Windows Azure Storage Abstractions and their Scalability Targets to get a better understanding of Windows Azure Storage service.

    Hope this helps!


    Best Regards,
    Carlos Sardo


  • Friday, August 17, 2012 5:20 PM
     
     

    Hi Manu - just following up - did your changes or the scalability targets post help?  Carlos' advice here is good - both of those could well have caused this, though my first bet is definitely the concurrent access.

    Thanks!


    -Jeff