Правильный способ настройки запроса на тайм-аут на Spring 5 WebClient

Question

Context

Я пытаюсь найти лучший способ объединить Spring 5 WebClient и Hystrix.Используя Hystrix, я устанавливаю разные таймауты для разных типов запросов, выполняемых WebClient.

Когда Hystrix достигает своего таймаута, я также хочу убедиться, что WebClient закрывает свое соединение.Ранее при использовании AsyncHttpClient это было сделано путем установки requestTimeout перед выполнением определенного вызова.Однако установить время ожидания запроса на WebClient намного сложнее, и его необходимо выполнить на ClientHttpConnector в соответствии с этим ответом .

Брайан Козел упоминает что оптимально использовать один и тот же ClientHttpConnector во всем приложении.Однако, поскольку для ClientHttpConnector должен быть задан тайм-аут для конкретного запроса, это кажется невозможным.

Вопрос

В реактиве Spring WebClient есть ли правильный способ установитьзапрашивать определенные таймауты, но все равно использовать один ClientHttpConnector?

Answer 1

Операции тайм-аута, которые вы можете настроить на клиентском соединителе, являются довольно низкими: они касаются времени ожидания сокета / соединения.Эту настройку нельзя выполнить на уровне запроса, поскольку соединения могут использоваться совместно и повторно использоваться в пуле соединений.

Этот вопрос касается тайм-аутов ответа, так как, кажется, вас волнует количество времени, необходимое для получения ответа,для каждого запроса.

В этом случае вы можете использовать оператор timeout для каждого запроса:

Mono<UserData> result = this.webClient.get()
                .uri("/user")
                .accept(MediaType.APPLICATION_JSON)
                .retrieve()
                .bodyToMono(UserData.class)
                .timeout(Duration.ofSeconds(10));

Оператор тайм-аута выбросит TimeoutException втрубопровод;Вы можете использовать один из операторов onError*, чтобы определить, что следует делать в этих случаях.Кроме того, вы можете напрямую использовать вариант timeout(Duration, Mono), который обеспечивает запасной вариант.