BlobRequestOptions.AbsorbConditionalErrorsOnRetry Property

Reference

Definition

Namespace:: Microsoft.Azure.Storage.Blob

Assembly:: Microsoft.Azure.Storage.Blob.dll

Package:: Microsoft.Azure.Storage.Blob v11.2.3

Important

Some information relates to prerelease product that may be substantially modified before it’s released. Microsoft makes no warranties, express or implied, with respect to the information provided here.

Gets or sets a value that indicates whether a conditional failure should be absorbed on a retry attempt for the request.

public bool? AbsorbConditionalErrorsOnRetry { get; set; }

member this.AbsorbConditionalErrorsOnRetry : Nullable<bool> with get, set

Public Property AbsorbConditionalErrorsOnRetry As Nullable(Of Boolean)

Property Value

Nullable<Boolean>

Examples

using (MemoryStream inputDataStream = new MemoryStream(inputData))
{
    BlobRequestOptions conditionalErrorRequestOptions = new BlobRequestOptions() { AbsorbConditionalErrorsOnRetry = true };

    CloudAppendBlob appendBlob = container.GetAppendBlobReference("appendBlob");
    appendBlob.UploadFromStream(inputDataStream, accessCondition: null, options: conditionalErrorRequestOptions);
}

Remarks

This option is used only by the CloudAppendBlob object in the UploadFrom* methods, the AppendFrom* methods, and the BlobWriteStream class. By default, it is set to false. Set this option to true only for single-writer scenarios. Setting this option to true in a multi-writer scenario may lead to corrupted blob data.

When calling "UploadFrom*" on an append blob, the Storage Client breaks the input data up into a number of data blocks, and uploads each data block with an "append block" operation. Normally, an "IfAppendPositionEqual" access condition is added to the append block operation, so that the upload operation will fail if some other process somewhere has appended data in the middle of this data stream. However, this can result in a false failure in a very specific case. If an append operation fails with a timeout, there is a chance that the operation succeeded on the service, but the "success" response did not make it back to the client. In this case, the client will retry, and then get an "append position not met" failure.

Setting this value to true results in the upload operation continuing when it sees an "append position not met" failure on retry - accounting for the above possibility. However, this loses protection in the multi-writer scenario - if multiple threads are uploading to the blob at once, and this value is set to true, some data may be lost, because the client thinks the data was uploaded, when in fact it was the other process' data.

Applies to

Share via