Tapestry Web App en Tomcat de vez en cuando escupe basura

Question

Tenemos una aplicación de Internet Tapestry-Spring-Hibernate en Tomcat 6, entregando unas 1000 solicitudes por segundo. Aleatoriamente, sin motivo aparente, una página solo muestra un montón de caracteres aleatorios en el navegador. Sin embargo, cuando la página se actualiza, se muestra bien. Aquí hay una captura de pantalla de la fuente de la página ilegible en Chrome:

aquí es lo que he encontrado hasta ahora:

1. No parece ser específica del navegador. He sido testigo de esto en Chrome y Firefox, pero los usuarios también han informado esto en IE 7 y versiones posteriores.
2. La carga en el servidor parece no tener correlación con cuando sucede esto.
3. Actualizar la página muestra la página normalmente, como si nada hubiera sucedido.
4. no veo nada relevante en el servidor o en los registros de la aplicación
5. La etiqueta de tipo de contenido de la página es <meta content="text/html; charset=utf-8" http-equiv="content-type"/>
6. Hay un par de otras aplicaciones web desplegadas en el mismo recipiente, uno de ellos al aire libre, pero no parecen exhibir esto en absoluto.

Mi pregunta es, alguien se ha encontrado con esto antes, y si es así, ¿pueden indicarme dónde debería empezar a buscar? ¿Es esto un problema con la página que tiene algo así como el tipo de contenido incorrecto o el servidor no puede manejarlo por alguna razón? ¿O podría ser esto un error de framework en Tapestry o en la aplicación en sí? Cualquier puntero es bienvenido. En este punto, no estoy seguro de dónde está el problema, por lo que no estaba seguro de si esto ocurre en ServerFault o si se queda aquí.

Answer 1

Esto parece estar relacionado con problemas de compresión gzip en el marco Tapestry (como lo sugiere @barnyr) y posiblemente sea un error de regresión en Tapestry 5.3. Para citar a Howard de un mailing list thread:

Creo que esto fue un error por el que, en determinadas circunstancias, un corrupto corriente GZIP del contenido de la página se transmite al cliente; esto es corregido en 5.2.6 seguro, pero pensé que también estaba corregido en 5.2.5.

La solución rápida es añadir el siguiente símbolo de configuración en el método de clase del módulo de la aplicación contributeApplicationDefaults:

configuration.add(SymbolConstants.GZIP_COMPRESSION_ENABLED, "false"); 

Por supuesto, esto desactiva la compresión gzip, pero podría una compensación vale la pena hacer.

cuestiones posiblemente relacionadas:

• GZip compression should be disabled if the request is over http 1.0
• Is GZIP compression compatible with XmlHttpRequest?

Answer 2

Lo más probable es que haya un error en la aplicación. (La mayoría de los errores son ... a pesar de la tendencia natural de los programadores a culpar a otra cosa.)

Sin embargo, podría ser un poco complicado rastrear este problema. Le sugiero que comience con las cosas estándar:

• Mire los registros de errores del servidor para ver si aparece algo extraño en el momento en que ocurre uno de estos "eventos".
• Mire los registros de acceso del servidor para ver si puede identificar la solicitud que produjo los datos basura.
• Habilite el depurador de su navegador y vea si puede rastrear la solicitud incorrecta de esa manera.

Si puede averiguar cuál fue la solicitud que produjo la mala respuesta, tendrá más tracción para encontrar la causa.

---

FWIW: no parece el resultado de un problema de codificación de caracteres. Eso se parece más a datos binarios o comprimidos.

Answer 3

Aquí hay una situación que me ha llevado a ver una página confusa. En la página de error, Tapestry establece un encabezado de respuesta llamado X-Tapestry-ErrorMessage. Evidentemente, las nuevas líneas no están permitidas en los encabezados (al menos en algunos navegadores) por lo que si ese encabezado tiene una nueva línea, se obtiene el galimatías. Un mensaje de error que estábamos configurando tenía una nueva línea al final. Lo cambié para eliminar cualquier nueva línea antes de configurar ese encabezado y luego la página de error se mostró correctamente.