java - libreria - Error provisional de Apache HttpClient: NoHttpResponseException

org apache http client methods httppost

Question

Tengo un servicio web que acepta un método POST con XML. Está funcionando bien, pero en alguna ocasión aleatoria, no se puede comunicar con el servidor al lanzar IOException con el mensaje The target server failed to respond . Las llamadas posteriores funcionan bien.

Ocurre principalmente, cuando hago algunas llamadas y luego dejo mi aplicación inactiva durante unos 10-15 minutos. La primera llamada que hago después de eso devuelve este error.

Probé un par de cosas ...

Configuré el controlador de reintentos como

HttpRequestRetryHandler retryHandler = new HttpRequestRetryHandler() {
public boolean retryRequest(IOException e, int retryCount, HttpContext httpCtx) {
if (retryCount >= 3){
Logger.warn(CALLER, "Maximum tries reached, exception would be thrown to outer block");
return false;
}
if (e instanceof org.apache.http.NoHttpResponseException){
Logger.warn(CALLER, "No response from server on "+retryCount+" call");
return true;
}
return false;
}
};
httpPost.getParams().setParameter(HttpMethodParams.RETRY_HANDLER, retryHandler);

Pero este reintento nunca fue llamado. (Sí, estoy usando la cláusula de ejemplo de derecha). Mientras se depura esta clase nunca se llama.

Incluso intenté configurar HttpProtocolParams.setUseExpectContinue(httpClient.getParams(), false); pero no sirve de nada. ¿Puede alguien sugerir lo que puedo hacer ahora?

IMPORTANTE Además de averiguar por qué obtengo la excepción, una de las preocupaciones importantes que tengo es ¿por qué no está trabajando aquí el retryhandler?

Answer 1

El mismo problema para mí en el cliente http 4.5.5 de Apache agregando un encabezado predeterminado

Conexión: cerrar

Resuelve el problema

Answer 2

Hoy en día, la mayoría de las conexiones HTTP se consideran persistentes a menos que se declare lo contrario . Sin embargo, para guardar los recursos del servidor, la conexión rara vez se mantiene abierta para siempre, el tiempo de espera predeterminado de la conexión para muchos servidores es bastante corto, por ejemplo, 5 segundos para el Apache httpd 2.2 y superior.

El error org.apache.http.NoHttpResponseException es muy probable que provenga de una conexión persistente que fue cerrada por el servidor.

Es posible establecer el tiempo máximo para mantener abiertas las conexiones no utilizadas en el grupo de clientes de Apache Http, en milisegundos.

Con Spring Boot, una forma de lograr esto:

public class RestTemplateCustomizers {
static public class MaxConnectionTimeCustomizer implements RestTemplateCustomizer {
@Override
public void customize(RestTemplate restTemplate) {
HttpClient httpClient = HttpClientBuilder
.create()
.setConnectionTimeToLive(1000, TimeUnit.MILLISECONDS)
.build();
restTemplate.setRequestFactory(
new HttpComponentsClientHttpRequestFactory(httpClient));
}
}
}
// In your service that uses a RestTemplate
public MyRestService(RestTemplateBuilder builder ) {
restTemplate = builder
.customizers(new RestTemplateCustomizers.MaxConnectionTimeCustomizer())
.build();
}

Answer 3

HttpClient 4.4 sufrió un error en esta área relacionado con la validación de posibles conexiones obsoletas antes de regresar al solicitante. No validó si una conexión estaba obsoleta, y esto da como resultado una NoHttpResponseException inmediata.

Este problema se resolvió en HttpClient 4.4.1. Ver este JIRA y las notas de lanzamiento.

Answer 4

La respuesta aceptada es correcta pero carece de solución. Para evitar este error, puede agregar setHttpRequestRetryHandler (o setRetryHandler para componentes de apache 4.4) para su cliente HTTP como en esta respuesta .

Answer 5

Lo más probable es que las conexiones persistentes mantenidas vivas por el administrador de conexión se vuelvan obsoletas. Es decir, el servidor de destino apaga la conexión en su extremo sin que HttpClient pueda reaccionar ante ese evento, mientras la conexión está inactiva, por lo que la conexión está semicerrada o "inactiva". Por lo general, esto no es un problema. HttpClient emplea varias técnicas para verificar la validez de la conexión al momento de su arrendamiento de la agrupación. Incluso si la verificación de la conexión obsoleta está inhabilitada y se utiliza una conexión obsoleta para transmitir un mensaje de solicitud, la ejecución de la solicitud generalmente falla en la operación de escritura con SocketException y se vuelve a intentar automáticamente. Sin embargo, en algunas circunstancias, la operación de escritura puede terminar sin una excepción y la operación de lectura posterior devuelve -1 (final del flujo). En este caso, HttpClient no tiene otra opción más que asumir que la solicitud fue exitosa, pero el servidor probablemente no respondió debido a un error inesperado en el lado del servidor.

La forma más sencilla de remediar la situación es desalojar las conexiones vencidas y las conexiones que han estado inactivas durante más tiempo, por ejemplo, a 1 minuto de la agrupación después de un período de inactividad. Para más detalles, consulte esta sección del tutorial de HttpClient .