Тайм-аут запроса HttpAsyncClient HC5

Question

Мы проверяем использование HttpAsyncClient из HttpClient 5.0, который будет создан во Flink AsyncFunction. Требования следующие:

1. Клиент создается по запросу;
2. SSL-сертификат должен быть загружен во время выполнения из файлов;
3. Запрос следует повторить в случае отказа указать c количество раз с задержкой Это часть теста:

final TlsStrategy tlsStrategy = ClientTlsStrategyBuilder.create().setSslContext(sslContext).build();
final PoolingAsyncClientConnectionManager cm = PoolingAsyncClientConnectionManagerBuilder.create()
        .setTlsStrategy(tlsStrategy)
        .build();
try (final CloseableHttpAsyncClient httpclient = HttpAsyncClients.custom()
        .setConnectionManager(cm)
        .setRetryStrategy(new RetryStrategy(3, TimeValue.ofMilliseconds(100)))
        .build()) {

    httpclient.start();
    RequestConfig requestConfig = RequestConfig.custom()
        .setConnectTimeout(Timeout.of(1000, TimeUnit.MILLISECONDS))
        .setResponseTimeout(Timeout.of(1000, TimeUnit.MILLISECONDS))
        .build();
    HttpClientContext httpContext = HttpClientContext.create();
    httpContext.setRequestConfig(requestConfig);
    final Future<SimpleHttpResponse> futurePostRequest =
          httpclient.execute(request1, httpContext, null);

    class RetryStrategy extends DefaultHttpRequestRetryStrategy {
        public RetryStrategy(
                final int maxRetries,
                final TimeValue defaultRetryInterval) {
            super(maxRetries, defaultRetryInterval,
                    Arrays.asList(
//                            InterruptedIOException.class,
                            UnknownHostException.class,
//                            ConnectException.class,
                            ConnectionClosedException.class,
                            SSLException.class),
                    Arrays.asList(
                            HttpStatus.SC_TOO_MANY_REQUESTS,
                            HttpStatus.SC_SERVICE_UNAVAILABLE));
        }

        protected boolean handleAsIdempotent(final HttpRequest request) {
            return true;
        }
    }

DefaultHttpRequestRetryStrategy переопределяется, чтобы разрешить повторную попытку в случае исключения SocketTimeout.

При тестировании стратегии повторных попыток для HTTP-сервера MOCK с задержка ответов в 1200 миллисекунд. Я выяснил, что часть запросов выполнена успешно, когда я ожидал сбоя всех запросов (поскольку тайм-аут установлен на 1000 миллисекунд). Например, я вызвал вышеуказанный код 10 раз одновременно, и 3 запроса были выполнены. Означает ли это, что время ожидания ответа может быть больше, чем настроено? Когда я отправил setMaxtTotal диспетчеру соединений ( cm.setMaxTotal (100) ), все запросы были неудачными, как и ожидалось. Почему увеличение количества подключений решает проблему (диспетчер подключений создается для каждого запроса, он не используется повторно для новых запросов / клиентов)? Это правильное решение для устранения проблемы с тайм-аутом?

Является ли использование PoolingAsyncClientConnectionManager оправданным для наших требований? А как иначе настроить контекст SSL и стратегию повтора?

Спасибо!