El paso a paso o código que encontrarás en este post es la solución más sencilla y efectiva que encontramos a tus dudas o dilema.
Solución:
Solo para agregar algunas configuraciones específicas, tenía una configuración similar (con proxy inverso de Apache 2.0.63 en Tomcat 5.0.27).
Para ciertas URL, el servidor Tomcat podría tardar unos 20 minutos en devolver una página.
Terminé modificando las siguientes configuraciones en el archivo de configuración de Apache para evitar que se agotara el tiempo de espera con su operación de proxy (con un gran factor de desbordamiento en caso de que Tomcat tardara más en devolver una página):
Timeout 5400
ProxyTimeout 5400
algunos antecedentes
ProxyTimeout solo no fue suficiente. Mirando la documentación de Timeout, estoy adivinación (No estoy seguro) de que esto se deba a que mientras Apache espera una respuesta de Tomcat, no fluye tráfico entre Apache y el navegador (o cualquier cliente http), por lo que Apache cierra la conexión con el navegador.
Descubrí que si dejaba la configuración de Tiempo de espera en su valor predeterminado (300 segundos), si la solicitud enviada por proxy a Tomcat tardaba más de 300 segundos en obtener una respuesta, el navegador mostraría una página de “Error de proxy 502”. Creo que este mensaje es generado por Apache, sabiendo que está actuando como un proxy inverso, antes de que cierre la conexión con el navegador (este es mi entendimiento actual, puede ser defectuoso).
La página de error del proxy dice:
Error de proxy
El servidor proxy recibió una respuesta no válida de un servidor ascendente. El servidor proxy no pudo manejar la solicitud GET.
Motivo: error al leer desde el servidor remoto
… lo que sugiere que la configuración de ProxyTimeout es demasiado corta, mientras que la investigación muestra que la configuración de tiempo de espera de Apache (tiempo de espera entre Apache y el cliente) también influye en esto.
Entonces, respondiendo mi propia pregunta aquí. Finalmente, determinamos que estábamos viendo errores 502 y 503 en el balanceador de carga debido a que se agotó el tiempo de espera de los subprocesos de Tomcat. A corto plazo aumentamos el tiempo muerto. A más largo plazo, solucionamos los problemas de la aplicación que causaban los tiempos de espera en primer lugar. Todavía es un misterio por qué los tiempos de espera de Tomcat se percibían como errores 502 y 503 en el balanceador de carga.
Puede usar proxy-inicial-no-agrupado
Consulte http://httpd.apache.org/docs/2.2/mod/mod_proxy_http.html:
Si se establece esta variable, no se reutilizará ninguna conexión agrupada si la conexión del cliente es una conexión inicial. Esto evita el mensaje de error “proxy: error al leer la línea de estado del servidor remoto” causado por la condición de carrera de que el servidor backend cerró la conexión agrupada después de que el proxy verificara la conexión y antes de que los datos enviados por el proxy llegaran al backend. Debe tenerse en cuenta que configurar esta variable reduce el rendimiento, especialmente con clientes HTTP/1.0.
Nosotros también tuvimos este problema. Lo arreglamos agregando
SetEnv proxy-nokeepalive 1
SetEnv proxy-initial-not-pooled 1
y girando keepAlive encendido todos los servidores apagados.
mod_proxy_http está bien en la mayoría de los escenarios, pero lo estamos ejecutando con mucha carga y todavía tenemos algunos problemas de tiempo de espera que no comprendemos.
Pero vea si la directiva anterior se ajusta a sus necesidades.
Si para ti ha sido de provecho este artículo, sería de mucha ayuda si lo compartieras con el resto entusiastas de la programación de esta forma contrubuyes a difundir nuestra información.