[BUG] readAddress(..) failed: Connection reset by peer for big file

[msangel]

Describe the bug
Exception for no reason during normal work of the application, during downloading a big file(3GB).

Exception or Stack Trace

Caused by: reactor.core.Exceptions$ReactiveException: io.netty.channel.unix.Errors$NativeIoException: readAddress(..) failed: Connection reset by peer
	at reactor.core.Exceptions.propagate(Exceptions.java:392)
	at reactor.core.publisher.BlockingSingleSubscriber.blockingGet(BlockingSingleSubscriber.java:97)
	at reactor.core.publisher.Mono.block(Mono.java:1703)
	at com.azure.storage.common.implementation.StorageImplUtils.blockWithOptionalTimeout(StorageImplUtils.java:128)
	at com.azure.storage.blob.specialized.BlobClientBase.downloadToFileWithResponse(BlobClientBase.java:903)
	at com.azure.storage.blob.specialized.BlobClientBase.downloadToFileWithResponse(BlobClientBase.java:873)
	at com.azure.storage.blob.specialized.BlobClientBase.downloadToFile(BlobClientBase.java:802)

To Reproduce

BlobContainerClient blobStorageService = new BlobContainerClientBuilder()
                .connectionString("my connection string")
                .containerName("my container name")
                .buildClient();
BlobClient blobClient = blobStorageService.getBlobClient("path/to/huge/file.txt");
Path tempFile = Files.createTempFile(null, null);
blobClient.downloadToFile(tempFile.toAbsolutePath().toString(), true);

Expected behavior
When the connection is active and blob downloading goes fine, there should be no timeout exceptions, even if the file being downloaded is huge. Setting retry policy should applied to network breaks but not for ordinal download with stable network.

Setup (please complete the following information):

• OS: Ubuntu 20.04.2 LTS
• IDE: IntelliJ
• Library/Libraries:

<properties>
    <netty.version>4.1.65.Final</netty.version>
    <reactor-bom.version>2020.0.7</reactor-bom.version>
</properties>
.....
<dependency>
    <groupId>com.azure</groupId>
    <artifactId>azure-storage-blob</artifactId>
    <version>12.11.1</version>
</dependency>
<dependency>
    <groupId>com.azure</groupId>
    <artifactId>azure-core-http-netty</artifactId>
    <version>1.10.0</version>
</dependency>

Information Checklist
Kindly make sure that you have added all the following information above and checkoff the required fields otherwise we will treat the issuer as an incomplete report

• Bug Description Added
• Repro Steps Added
• Setup information Added

[gapra-msft]

Hi @msangel

Thank you for reporting this issue.

It looks like the default retry policy for downloads is to not retry, could you please try using the downloadToFileWithResponse API and set DownloadRetryOptions.maxRetryRequests? The retry will continue at the point where the download started to fail.

Here is a similar issue #21066

[msangel]

@gapra-msft
Yes, I have implemented the behavior using DownloadRetryOptions#maxRetryRequests, but that has two points:

1. Not clear how many retries I should set there. Is 10 good? Maybe I need 1000? I put Integer.MAX_VALUE there. Am I good? What if file will be 100GB or client will be connected via a slow GPRS modem?
2. The current behavior of BlobClient#downloadToFile is broken, because it throws an exception for no visible reason,