TransferManager Class

Definition

This class contains a collection of methods (and structures associated with those methods) which perform higher-level operations. Whereas operations on the URL types guarantee a single REST request and make no assumptions on desired behavior, these methods will often compose several requests to provide a convenient way of performing more complex operations. Further, we will make our own assumptions and optimizations for common cases that may not be ideal for rarer cases.

public class TransferManager
Inheritance
java.lang.Object
TransferManager

Fields

BLOB_DEFAULT_DOWNLOAD_BLOCK_SIZE

The default size of a download chunk for download large blobs.

Methods

downloadBlobToFile(AsynchronousFileChannel file, BlobURL blobURL, BlobRange range, TransferManagerDownloadFromBlobOptions options)

Downloads a file directly into a file, splitting the download into chunks and parallelizing as necessary.

uploadFileToBlockBlob(final AsynchronousFileChannel file, final BlockBlobURL blockBlobURL, final int blockLength, Integer maxSingleShotSize, final TransferManagerUploadToBlockBlobOptions options)

Uploads the contents of a file to a block blob in parallel, breaking it into block-size chunks if necessary.

uploadFromNonReplayableFlowable(final Flowable<ByteBuffer> source, final BlockBlobURL blockBlobURL, final int blockSize, final int numBuffers, final TransferManagerUploadToBlockBlobOptions options)

Uploads the contents of an arbitraryFlowable  to a block blob. This Flowable need not be replayable and therefore it may have as its source a network stream or any other data for which the replay behavior is unknown (non-replayable meaning the Flowable may not return the exact same data on each subscription).

To eliminate the need for replayability on the source, the client must perform some buffering in order to ensure the actual data passed to the network is replayable. This is important in order to support retries, which are crucial for reliable data transfer. Typically, the greater the number of buffers used, the greater the possible parallelism. Larger buffers means we will have to stage fewer blocks. The tradeoffs between these values are context-dependent, so some experimentation may be required to optimize inputs for a given scenario.

Note that buffering must be strictly sequential. Only the upload portion of this operation may be parallelized; the reads cannot be. Therefore, this method is not as optimal as uploadFileToBlockBlob(AsynchronousFileChannel, BlockBlobURL, int, Integer, TransferManagerUploadToBlockBlobOptions) and if the source is known to be a file, that method should be preferred.

Applies to