Какой самый короткий способ настроить тайм-аут простоя подключения в версии Apache HttpClient 4.3?
Я просмотрел документацию и ничего не нашел. Моя цель - уменьшить открытые соединения до минимального пост-пикового уровня.
например, в Jetty Client 8.x вы можете установить httpClient.setIdleTimeout: http://download.eclipse.org/jetty/stable-8/apidocs/org/eclipse/jetty/client/HttpClient.html#setIdleTimeout(long)
Тайм-аут устанавливается в RequestConfig, поэтому вы можете установить значение по умолчанию при вызове HttpClientBuilder.
Например, если ваша переменная таймаута находится в секундах для создания пользовательского RequestConfig, вы можете сделать что-то вроде этого:
RequestConfig config = RequestConfig.custom()
.setSocketTimeout(timeout * 1000)
.setConnectTimeout(timeout * 1000)
.build();
Затем вы можете создать свой HttpClient для параметра RequestConfig по умолчанию следующим образом:
HttpClients.custom()
.setDefaultRequestConfig(config);
не может установить время ожидания простоя в конфигурации для Apache HTTP Client. Причина в том, что при этом возникают накладные расходы.
В документации четко указано, почему, и приводится пример реализации монитора простоя подключений, которую вы можете скопировать. По существу это еще один поток, который вы запускаете для периодического вызова closeIdleConnections on HttpClientConnectionManager
http://hc.apache.org/httpcomponents-client-ga/tutorial/html/connmgmt.html
Одним из основных недостатков классической блокирующей модели ввода-вывода является то, что сетевой сокет может реагировать на события ввода-вывода только при блокировке в операции ввода-вывода. Когда соединение будет отправлено обратно менеджеру, он может быть сохранен, однако он не может контролировать состояние сокета и реагировать на любые события ввода-вывода. Если соединение закрывается на стороне сервера, клиентское соединение не может обнаружить изменение состояния соединения (и реагировать соответствующим образом, закрыв сокет на своем конце). HttpClient пытается смягчить проблему, проверяя, является ли соединение "устаревшим", то есть более недействительным, поскольку оно было закрыто на стороне сервера, прежде чем использовать соединение для выполнения HTTP-запроса. Проверка устаревших соединений не на 100% надежна и добавляет от 10 до 30 мс служебных данных для каждого выполнения запроса. Единственное возможное решение, которое не включает один поток на модель сокета для незанятых соединений, представляет собой выделенный поток монитора, используемый для выключения соединений, которые считаются истекшими из-за длительного периода бездействия. Поток монитора может периодически вызывать метод ClientConnectionManager # closeExpiredConnections() для закрытия всех истекших соединений и выключения закрытых подключений из пула. Кроме того, он может также вызвать метод ClientConnectionManager # closeIdleConnections(), чтобы закрыть все соединения, которые простаивали в течение определенного периода времени.