none
"waithandle array may not be empty" in Blob.UploadFromStream

    Question

  • Hello,

    I am receiving this error when using UploadFromStream. It only happens sometimes, but it happens consistently on one file I am trying to upload.

    The stack looks like this;

     

    Microsoft.WindowsAzure.StorageClient.DLL!Microsoft.WindowsAzure.StorageClient.Tasks.Task<Microsoft.WindowsAzure.StorageClient.Tasks.NullTaskReturn>.Result.get() + 0x98 bytes	
    Microsoft.WindowsAzure.StorageClient.DLL!Microsoft.WindowsAzure.StorageClient.Tasks.Task<Microsoft.WindowsAzure.StorageClient.Tasks.NullTaskReturn>.ExecuteAndWait() + 0x222 bytes	
    Microsoft.WindowsAzure.StorageClient.DLL!Microsoft.WindowsAzure.StorageClient.TaskImplHelper.ExecuteImpl(System.Func<System.Collections.Generic.IEnumerable<Microsoft.WindowsAzure.StorageClient.Tasks.ITask>> impl = {Method = {System.Reflection.RuntimeMethodInfo}}) + 0x84 bytes	
    Microsoft.WindowsAzure.StorageClient.DLL!Microsoft.WindowsAzure.StorageClient.CloudBlob.UploadFromStream(System.IO.Stream source = {System.ServiceModel.Dispatcher.StreamFormatter.MessageBodyStream}, Microsoft.WindowsAzure.StorageClient.BlobRequestOptions options = {Microsoft.WindowsAzure.StorageClient.BlobRequestOptions}) + 0x119 bytes	

    The sequence of events is this: First we try to upload with UploadFromStream. This results in StorageErrorCode.BlobAlreadyExists (although it didn't), and a 0-byte blob is created. We then attempt to retry the UploadFromStream to overwrite the 0-byte blob, and this exception is thrown.


    • Edited by Porges Wednesday, September 08, 2010 2:19 AM fix font
    • Moved by Brian AurichMicrosoft employee Thursday, September 30, 2010 6:55 PM migration (From:Windows Azure - Archive)
    Wednesday, September 08, 2010 2:18 AM

All replies

  • Hi,

    Does it happen in dev storage or cloud storage? Could you provide a demo project that can reproduce this issue? (with the file that you said can consistently  repro it). You may upload the project to http://skydrive.com and paste download link here. (Please mask your username and password in connection string)


    Please remember to mark the replies as answers if they help and unmark them if they provide no help. Windows Azure Platform China Blog: http://blogs.msdn.com/azchina/default.aspx
    Thursday, September 09, 2010 7:20 AM
    Moderator
  • Hi,

    Do you have any progress on this issue?


    Please remember to mark the replies as answers if they help and unmark them if they provide no help. Windows Azure Platform China Blog: http://blogs.msdn.com/azchina/default.aspx
    Tuesday, September 14, 2010 9:33 AM
    Moderator
  • Hi Allen,

    I still don't have a 100% reproducible test case. Some other members of my team are encountering this also, so I'll see if anyone has some idea of what's causing it.

    Sunday, December 05, 2010 11:36 PM
  • I've spent some time trying to get a repro today but haven't had much luck. There isn't much difference left between my code and what we're actually using apart from the fact that the real code accepts streams via a web interface and my code is just opening files. If I can get it to do the same then I'll post it here. In the mean time, here are is what I'm seeing, exactly:

    This is happening in the dev environment.

    I start with a completely empty dev storage and fresh deployment.

    There are two files. The client calls the webservice with a stream, one at a time. The order is as you'd expect from the file names.

    For each call, the webservice fetches the container reference, gets a blob reference, adds some metadata and calls UploadFromStream. The metadata is just two short strings: {"blobType":"JobData"}. The blob is named after the file, concatted with a timestamp in "yyyyMMddHHmmssfff" format.

    The first call works fine, and the file is uploaded successfully.

    The second call dies inside UploadFromStream with "Blob already exists". At this point, a 0-byte blob is now created inside the dev storage. I have stepped through and confirmed that the file only exists after we call UploadFromStream.

    The upload is retried for the second file, and dies inside UploadFromStream "Waithandle array may not be empty" (and stack trace as originally posted). (I'm not actually sure this is valid since the Stream would probably be in a non-usable state by now... so this may be the cause.)

     

    The files are here: https://cid-067f0dc22bbf1eff.skydrive.live.com/redir.aspx?resid=67F0DC22BBF1EFF!151

    I've shared them just with you because they're not public :)

    Monday, December 06, 2010 4:26 AM
  • I've had more of a look into the first error ("Blob already exists"). I've managed to narrow it down, and it appears to be due to a race condition or something in CloudBlob.UploadFromStream. If I set CloudBlob.ServiceClient.ParallelismThreadCount = 1, then the "Blob already exists" exception disappears.

    Is someone able to look into this?

    Thursday, December 09, 2010 11:06 PM
  • Hi,

    Since this is an old thread I'd like to know whether you still see this issue when using 1.3 SDK. If you do please post a repro project. I will report it to the proper team to have a look.


    Please remember to mark the replies as answers if they help and unmark them if they provide no help. Windows Azure Platform China Blog: http://blogs.msdn.com/azchina/default.aspx
    Friday, December 10, 2010 1:15 AM
    Moderator
  • We have identified this issue with the current Windows Azure Storage Client Library. I have written up a post on the Windows Azure Storage Team blog detailing the issue and providing mitigations / workaround code to address it until it is fixed in a future release of the SDK. 

    http://blogs.msdn.com/b/windowsazurestorage/archive/2011/02/23/windows-azure-storage-client-library-parallel-single-blob-upload-race-condition-can-throw-an-unhandled-exception.aspx

     

    Joe

    Thursday, February 24, 2011 5:56 PM