Tapestry Web App na Tomcat od czasu do czasu wypluwa śmieci

Question

Mamy webastę Tapestry-Spring-Hibernate działającą na Tomcat 6, przekazującą około 1000 żądań na sekundę. Losowo, bez wyraźnego powodu, strona wyświetla tylko kilka losowych znaków w przeglądarce. Jednak po odświeżeniu strony wyświetla się dobrze. Oto screen-shot źródła strony zniekształcone na Chrome:

Oto co znalazłem do tej pory:

1. To nie wydaje się być specyficzna przeglądarki. Byłem tego świadkiem w Chrome i Firefoksie, ale użytkownicy zgłosili to również w IE 7 i nowszych.
2. Załadowanie na serwerze wydaje się nie mieć żadnej korelacji, gdy tak się stanie.
3. Odświeżanie strony powoduje wyświetlenie strony normalnie, tak jakby nic się nie wydarzyło.
4. Nie widzę niczego odpowiedniego serwera lub w dziennikach aplikacji
5. tag Content-Type na stronie <meta content="text/html; charset=utf-8" http-equiv="content-type"/>
6. Istnieje kilka innych webapps rozmieszczone na tym samym pojemniku, jedna jest Alfresco, ale oni w ogóle tego nie wykazują.

Moje pytanie brzmi, czy ktoś już kiedyś to zrobił, a jeśli tak, to czy mogą wskazać mi, gdzie powinienem zacząć szukać? Czy jest to problem ze stroną zawierającą coś w rodzaju niepoprawnego typu treści lub serwer nie może z jakiegoś powodu sobie z tym poradzić? Czy może to być ramowy błąd w Tapestry lub w samej aplikacji? Wszelkie wskazówki są mile widziane. W tym momencie nie jestem pewien, gdzie jest problem, więc nie byłem pewien, czy to się dzieje w ServerFault, czy zostaje tutaj.

Answer 1

Wydaje się to być związane z problemami kompresji gzip w strukturze Tapestry (zgodnie z sugestią @barnyr) i prawdopodobnie jest to błąd regresji w Tapestry 5.3. Zacytować Howarda z mailing list thread:

wierzę, że to był błąd, gdzie w pewnych okolicznościach uszkodzony strumień GZIP zawartości stron byłyby przesyłane do klienta; na pewno jest to poprawione w wersji 5.2.6, ale pomyślałem, że zostało to również naprawione w wersji 5.2.5.

Szybka poprawka jest dodać następujący symbol konfiguracji w metodzie klasy Moduł aplikacji contributeApplicationDefaults:

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

To oczywiście wyłącza gzip kompresja, ale może kompromis warto podjąć.

Prawdopodobnie powiązane kwestie:

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

Answer 2

Jest to najprawdopodobniej błąd w aplikacji. (Większość błędów jest ... pomimo naturalnej tendencji programistów do obwiniania czegokolwiek innego.)

Jednak może być nieco trudny do wyśledzenia tego problemu. Proponuję zacząć od standardowych rzeczy:

• Sprawdź dzienniki błędów serwera, aby zobaczyć, czy coś dziwnego pojawia się w momencie wystąpienia jednego z tych "zdarzeń".
• Przejrzyj dzienniki dostępu do serwera, aby sprawdzić, czy można zidentyfikować żądanie, które wygenerowało dane śmieci.
• Włącz swój debuger przeglądarki i sprawdź, czy możesz w ten sposób wyśledzić złe żądanie.

Jeśli możesz dowiedzieć się, jakie było żądanie, które wywołało złą reakcję, będziesz mieć większą przyczepność w znajdowaniu przyczyny.

---

FWIW - to nie wygląda na wynik problemu z kodowaniem znaków. To wygląda bardziej jak dane binarne lub skompresowane.

Answer 3

Oto jedna z sytuacji, która doprowadziła mnie do wyświetlenia zniekształconej strony. Na stronie błędu Tapestry ustawia nagłówek odpowiedzi o nazwie X-Tapestry-ErrorMessage. Widocznie nowe linie nie są dozwolone w nagłówkach (przynajmniej w niektórych przeglądarkach), więc jeśli ten nagłówek ma znak nowej linii, dostajesz bełkot. Jeden z komunikatów o błędach, który ustawialiśmy, miał nową linię. Zmieniłem go, aby usunąć wszelkie nowe linie przed ustawieniem tego nagłówka, a następnie strona błędu została wyświetlona poprawnie.