java - org - Apache HttpClient 4.3: configuración del tiempo de espera inactivo de la conexión

httpclientbuilder maven

Question

¿Cuál es la forma más corta de configurar el tiempo de espera inactivo de la conexión en la versión Apache HttpClient 4.3?

He buscado en la documentación y no he podido encontrar nada. Mi objetivo es reducir las conexiones abiertas a un pico de servidor de publicación mínimo.

por ejemplo, en Jetty Client 8.x puede establecer httpClient.setIdleTimeout: http://download.eclipse.org/jetty/stable-8/apidocs/org/eclipse/jetty/client/HttpClient.html#setIdleTimeout(long)

Answer 1

El tiempo de espera se establece en RequestConfig para que pueda establecer el valor predeterminado cuando se llama a HttpClientBuilder.

Por ejemplo, suponiendo que su variable de tiempo de espera está en segundos para crear su RequestConfig personalizado, podría hacer algo como esto:

RequestConfig config = RequestConfig.custom()
    .setSocketTimeout(timeout * 1000)
    .setConnectTimeout(timeout * 1000)
    .build();

A continuación, podría compilar su HttpClient configurando RequestConfig por defecto de la siguiente manera:

HttpClients.custom()
    .setDefaultRequestConfig(config);

Answer 2

No puede establecer un tiempo de espera de conexión inactiva en la configuración para Apache HTTP Client. La razón es que hay una sobrecarga de rendimiento al hacerlo.

La documentación indica claramente por qué, y da un ejemplo de una implementación de monitor de conexión inactiva que puede copiar. Básicamente, este es otro hilo que ejecuta periódicamente para llamar a closeIdleConnections en HttpClientConnectionManager

http://hc.apache.org/httpcomponents-client-ga/tutorial/html/connmgmt.html

Una de las principales deficiencias del clásico modelo de E / S de bloqueo es que el zócalo de red puede reaccionar a los eventos de E / S solo cuando está bloqueado en una operación de E / S. Cuando se libera una conexión de nuevo al administrador, se puede mantener activa, pero no se puede monitorear el estado del socket y reaccionar ante cualquier evento de E / S. Si la conexión se cierra en el lado del servidor, la conexión del lado del cliente no puede detectar el cambio en el estado de la conexión (y reacciona de manera adecuada cerrando el socket en su extremo). HttpClient intenta mitigar el problema probando si la conexión está "obsoleta", que ya no es válida porque se cerró por el lado del servidor, antes de usar la conexión para ejecutar una solicitud HTTP. La verificación de conexión obsoleta no es 100% confiable y agrega una sobrecarga de 10 a 30 ms a cada ejecución de solicitud. La única solución factible que no implica un modelo de subproceso único por socket para las conexiones inactivas es un subproceso de monitor dedicado utilizado para desalojar las conexiones que se consideran expiradas debido a un largo período de inactividad. El subproceso del monitor puede llamar periódicamente al método ClientConnectionManager # closeExpiredConnections () para cerrar todas las conexiones caducadas y desalojar las conexiones cerradas del grupo. También se puede llamar opcionalmente al método ClientConnectionManager # closeIdleConnections () para cerrar todas las conexiones que han estado inactivas durante un período de tiempo determinado.