tomcat – ByteBlog

Wenn der Redirect im Halse stecken bleibt

Gestern haben wir unseren nexus-Server auf den neuesten Stand gebracht und kurz danach funktionierten unsere ant-Skripte zum Herunterladen von Artefakten aus dem nexus nicht mehr. Das Problem war schnell gefunden, die nexus Entwickler haben den Status-Code für einen Redirect von 301 (moved permanently) auf 307 (temporary redirect) geändert. Das ist wohl moderner und kann den Client vom Caching abhalten. Leider haben die ant Entwickler das in ihren alten Versionen, die wir einsetzen, noch nicht gewusst und kommen damit nicht klar.

Da der nexus aber in einem Servlet Container läuft, kann man einen Filter einrichten, der alle Redirects mit Status-Code 307 (temporary redirect) auf den alten Wert 302 (moved temporarily) ändert.

Mit angezogener Handbremse

Seit einigen Wochen hatten wir ein Problem mit unserem Softwareloadbalancer, der auf einem unserer Tomcatserver läuft. Dachten wir.

Die durchschnittliche Last (loadavg) auf dem Server ging in relativ regelmäßigen zweistündlichen Abständen auf über zehn. Da die Lastprobleme mit dem Lastverteiler umzogen hatten wir den nebenher laufenden Tomcat relativ früh als Verursacher der Probleme ausgeschlossen.

Ein Irrtum.

Wegen eines anderen Problemes haben wir während einer solchen hochlast Phase den Tomcat mittels

kill -quit $TOMCAT_PID

mehrere Threaddumps schreiben lassen. Bei der Analyse dieser Dumps fiel uns dann auf, dass ein übervorsichtiger Programmierer eine Garbage Collection bei jedem Aufruf seines Servlets veranlasste.

Glücklicherweise kann mittels Parameter der JavaVM das Beachten dieser Aufforderung ausgetrieben werden. Seit wir die Option -XX:+DisableExplicitGC für die Tomcat JavaVM nutzen, sind alle Lastprobleme verschwunden. Ebenso zeigte sich, dass die Anzahl der möglichen Anfragen an das Servlet von etwa vier Anfragen pro Sekunde auf etwa 200 Anfragen pro Sekunde hochschnellten.

Und netterweise sind in dem Servlet auch die Aufrufe von System.gc() verschwunden.