AsyncFutureCompletionExecutor против цикла событий Netty - PullRequest
Новая
       85

AsyncFutureCompletionExecutor против цикла событий Netty

0 голосов
/ 19 июня 2020

Я использую AWS SDK для Java 2.0 вместе с HTTP-клиентом Netty, и я заметил, что есть два разных пула потоков, которые могут эффективно обрабатывать ответ. Первый - это ThreadPoolExecutor, который можно переопределить как часть самого клиента службы, например, 

DynamoDbAsyncClient dynamoClient = DynamoDbAsyncClient.builder()
                .httpClient(httpClient)
                .asyncConfiguration(ClientAsyncConfiguration.builder()
                        .advancedOption(SdkAdvancedAsyncClientOption.FUTURE_COMPLETION_EXECUTOR, awsSdkFutureCompletionExecutor)
                        .build())

Второй - событие l oop клиента HTTP Netty. В зависимости от того, где я присоединяюсь к потоку, я вижу, что он обрабатывается пулом потоков aws-java-sdk-NettyEventLoop или sdk-async-response.

Если я вызываю dynamoClient.query(request).join(), я вижу, что aws-java-sdk-NettyEventLoop продолжается любая дальнейшая обработка, тогда как dynamoClient.query(request).whenComplete(...) означает, что поток sdk-async-response выполняет обработку.

Есть ли рекомендуемый подход? Должен ли я предпочесть обработку в одном пуле потоков другому?

1 Ответ

0 голосов
/ 22 июня 2020

Я подозреваю, что на самом деле знаю ответ на этот вопрос. Я считаю, что ответ передается в пул потоков sdk-async-response для защиты от того, кто-то выполняет блокирующий вызов в обработчике ответа для запроса и, таким образом, блокирует событие Netty l oop. Итак, чтобы ответить на мой собственный вопрос, я думаю, что обработка ответов должна выполняться в пуле потоков sdk-async-response. Вероятно, было бы хорошо в будущей версии не передавать ответ за пределами события Netty l oop, с обычными оговорками, но на данный момент это кажется невозможным.

...