Microsoft Azure Storage SDK для подключений Java V10 Max - PullRequest
Новая
       8

Microsoft Azure Storage SDK для подключений Java V10 Max

0 голосов
/ 10 октября 2018

Я использую Microsoft Azure Storage SDK для java, и конкретные координаты артефакта: com.microsoft.azure:azure-storage-blob:10.1.0.

Мой пример использования заключается в потоковой передаче входящих загрузок с моего сервера в Azure через клиент Azure, предоставленныйбиблиотека:

[Client] ---upload---> [My Server] ---put object---> [Azure]

Хотелось бы узнать, сколько одновременных подключений может обработать клиент Azure и можно ли настроить это значение?

Я пыталсянастроить channelPoolSize следующим образом: 

    final NettyClient.Factory factory = new NettyClient.Factory(
             new Bootstrap(),
             0,
             10000); //<--- channelPoolSize
    final HttpClient client = factory.create(null);

    final PipelineOptions pipelineOptions = new PipelineOptions()
            .withLogger(new Slf4jLogger(LOG))
            .withRequestRetryOptions(NO_RETRY)
            .withClient(client);

    final HttpPipeline pipeline = StorageURL.createPipeline(credential, pipelineOptions);
    final URL endpoint = endpointForAccountOrThrow(accountName);
    final ServiceURL serviceURL = new ServiceURL(endpoint, pipeline);
    containerURL = serviceURL.createContainerURL(containerName);

Но я вижу, что около 250 одновременных загрузок клиент начинает сбой с:

java.util.concurrent.TimeoutException: null at io.reactivex.internal.operators.single.SingleTimeout$TimeoutMainObserver.run(SingleTimeout.java:115) at io.reactivex.internal.schedulers.ScheduledDirectTask.call(ScheduledDirectTask.java:38) at io.reactivex.internal.schedulers.ScheduledDirectTask.call(ScheduledDirectTask.java:26) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748)

Есть идеи?

Здравствуйте, я обнаружил проблему и делюсь ею здесь на случай, если она пригодится кому-то еще.Проблема заключалась в том, что по мере роста числа пользователей время потоковой передачи становилось все выше и выше.Около 250 одновременных загрузок, были запросы, занимающие более 1 минуты, но у меня была общая политика повторения, определенная следующим образом:

private static RequestRetryOptions NO_RETRY = new RequestRetryOptions( RetryPolicyType.EXPONENTIAL, 1, null, null, null, null);

Такая политика заставляет запрос бытьЗавершено в течение минуты (по умолчанию это tryTimeout).

После прочтения документа java RequestRetryOptions:

* @param tryTimeout * Indicates the maximum time allowed for any single try of an HTTP request. A value of {@code null} means that * you accept our default. NOTE: When transferring large amounts of data, the default TryTimeout will probably * not be sufficient. You should override this value based on the bandwidth available to the host machine and * proximity to the Storage service. A good starting point may be something like (60 seconds per MB of * anticipated-payload-size).

я переключился на запросповторите политику, установив значение tryTimeout в зависимости от размера контента.Это решило мою проблему

...