V12 SDK deprecation impact

[rohitgkr]

Which service(blob, file, queue, table) does this issue concern?

Blob/BlockBlobClient/BlobContainerClient

Which version of the SDK was used?

Azure.Storage.Blobs V12.3.0 With APIs such as BlobRequestOptions & CloudBlockBlob being deprecated in V12 SDK I couldn't find any documentation indicating their replacement in the current storage SDK.

1. What is the default retry policy in V12 SDK?
2. Is there a way to specify parallelism in threads for upload as BlobRequestOptions is not available in BlobContainerClient or in BlockBlobClient?
3. Is the expectation for the caller to call BlockBlobClient.StageBlockAsync from thread pool threads or TPL thread delegates? This is unlike the previous SDK implementation where the SDK used threads specified inside BlobRequestOptions to automatically manage block blob upload parallelism. Thanks.

[rohitgkr]

i've looked into the SDK source & inferred the following. Please comment with any additions or corrections.

• BlockBlobClient could be used directly but threads & parallelism must be managed by the end user.
• BlobClient orchestrates threads via StorageTransferOptions passed in during Upload*
• Staged uploads for over 265MB content and single upload upto 256MB
• By default (across various classes & parameters) the end state is => Retry policy : Exponential backoff upto 5 attempts, 1min max delay (overridden via BlobClientOptions) Concurrency : 5, Upload chunk size : 256MB Download chunk size : 256 MB Block blob size : 4MB or 8MB if not specified, if specified => max 100MB Max blocks : 50K HttpClient timeout : 100secs (change via BlobClientOptions.Transport) HttpClientHandler.MaxRequestContentBufferSize : 0. This is irrelevant as .NET Core now uses SocketsHttpHandler & SDK StorageTransferOptions can be used for single & block size spec.

[Petermarcu]

Issue moved to Azure/azure-sdk-for-net #11158 via ZenHub