java - ejemplo - Tomcat/IIS cierra el socket después de que se complete la respuesta http
websocket javascript ejemplo (2)
Estoy usando JBoss 4.0.4 GA, que tiene Tomcat Servlet Container 5.5. También tengo IIS 6.0 redirigido a este JBoss. (a través del conector tomcat de IIS, que se utiliza como filtro ISAPI en IIS). Todo funciona bien, configuró a los trabajadores como se describe.
Aquí hay una parte del archivo workers.properties del conector:
#
# Defining a worker named ajp13 and of type ajp13
# Note that the name and the type do not have to match.
#
worker.jboss0_ajp13.port=8009
worker.jboss0_ajp13.type=ajp13
worker.jboss0_ajp13.host=localhost
worker.jboss0_ajp13.socket_keepalive=1
worker.jboss0_ajp13.socket_timeout=300
Pero cuando se conecta a la aplicación a través de IIS (puerto 80), por cada respuesta HTTP completa para solicitud HTTP, el socket se cierra (FIN se envía en la capa TCP). Esto causa ralentizaciones severas, ya que la aplicación está trabajando sobre WAN. (Para cada toma cerrada, se debe establecer otra, que tarda 500 ms).
Esto no sucede cuando se conecta directamente al servidor web JBoss, y tampoco ocurre cuando se conecta a un directorio virtual diferente en el mismo instalador WebServer de IIS (es decir, Keep-Alive en IIS también está configurado).
Esto ocurre con la última versión del conector IIS de tomcat.
¿Sabes si hay un error en el conector o hay un problema con mi configuración?
Gracias por adelantado,
Enrique.
Es probable que IIS esté cerrando el socket. La conexión entre JBoss e IIS debería ser irrelevante para que el socket HTTP sea persistente o no. Asegúrese de que IIS esté configurado para admitir conectores HTTP / 1.1 persistentes.
Sin embargo, señala que otro directorio virtual en IIS no tiene el mismo problema. Podría ser un problema con el directorio virtual específico que está teniendo problemas. Sin embargo, también podría ser algo en el conector IIS / Tomcat.
Para investigar si se trata del conector IIS / Tomcat, intente configurar
worker.jboss0_ajp13.connection_pool_size = 10 worker.jboss0_ajp13.connection_pool_timeout = 600
para ver si hace alguna diferencia en absoluto. Consulte Documentos de Tomcat Workers (incluida la sección en la parte inferior "A sample worker.properties"). Vea si alguno de los parámetros mencionados allí lo ayudan.
Archivé un error en Bugzilla para el redirector de tomcat IIS, y esta es la respuesta que tengo:
Hasta 1.2.27, este era el comportamiento del conector IIS (IIS obliga a todas las extensiones ISAPI a implementar su propio HTTP a mantenerse activo, y el conector IIS no lo hizo).
En 1.2.27 hay soporte experimental, de tiempo de construcción, para la codificación fragmentada HTTP 1.1, que debería permitir conexiones persistentes. (He estado usando casi el mismo código en sistemas de producción durante aproximadamente 4 años, pero debe considerarse experimental en la base de código JK hasta que se haya estabilizado por un tiempo).
Toma el binario descompuesto de uno de los espejos de descarga y lee sobre cómo configurar la codificación fragmentada en las notas de la versión 1.2.27 (tienes que obtener la versión correcta y habilitarla en tu configuración). Puede verificar que el conector esté usando codificación fragmentada con inicio de sesión de depuración, y un rastreo de TCP / Wireshark debería mostrar las conexiones que se reutilizan.
Si todavía está recibiendo conexiones cerradas, y los registros muestran que el conector está intentando (o debería intentar) la codificación fragmentada, entonces probablemente sea mejor debatir en la lista de usuarios y luego volver a abrir con otro registro de depuración Wireshark traza + conector una vez que estoy seguro de que hay un problema.
Entonces, lo que hice:
- Coloque isapi_redirect.dll con soporte de fragmentación.
Configurado isapi_redirect.properties con lo siguiente:
enable_chunked_encoding=1Reinició IIS.