ITBlog

Bei Java gibt es keine C-typischen Schutzverletzungen mehr - könnte man annehmen. Leider wurde ich in letzter Zeit gleich bei mehreren Kunden eines Besseren belehrt: Bei einem SAP XI Kunden stürtzt die Sun Java VM (1.4.2_09) auf einem Itanium Rechner jede Stunde mit einer Accesss Violation ab (wenn der Compiler Thread des HotSpot JIT Compilers eine unserer Java Methoden übersetzen will). Offensichtlich hat die IA64 Version der Sun-VM hier einen Implementierungsfehler. Ich hoffe das Abschalten des JIT Compilers für diese eine Methode (mittels HotSpot Command File) bringt erst mal Linderung, bis die SAP Service Meldung bei Sun angekommen ist. Warum müssen Kunden immer auf solch exotische Systemlandschaften bauen? Bei einem anderen Kunden wurde der JVM Crash nicht durch einen Implementierungsfehler des JIT Compilers ausgelöst, sondern in externem nativer Code. Dies ist eine Fehlerquelle, eigentlich häufiger als die VM Fehler. In unserem Fall war es die Sun JDBC-ODBC Bridge (bzw. der damit eingebundene alte ODBC Treiber). Zum Glück waren wir bei dem Kunden sowieso dabei die letzten ODBC Bridges zu entfernen - Problem also schnell behoben. Weitere Gründe für Crashes in der JVM sind Hardware Probleme. Insbesondere defekter Speicher führt nicht selten zu zufälligen Abstürzen. Hier mein Tipp für Administration und Systemmanagement: Für einen stabilen Betrieb ist es unbedingt erforderlich mit solchen Abstürzen zu rechnen: zum Einen muss das Gesamtsystem einen solchen Abbruch überstehen (Restart, Redundanz und wiederaufsetzen aus jeder Situation). Aber ebenso wichtig ist es, im Falle eines solchen Absturzes schnell der Ursache auf die Spur zu kommen. Sun's HotSpot VM schreibt sehr informative Crash Dumps: ein File mit dem Namen hs_err_pid.log. Damit dieses File angelegt werden kann sollte der User der die JVM startet unbedingt Schreibrechte im aktuellen Startverzeichnis haben. Treten unerwartete Java Abstürze auf sollte Ihre erste Aktion sein, nach diesen Files zu suchen. Sie können sich auch nicht darauf verlassen, dass der Betriebsystem eigene Überwachungsmechanismus (Dr. Watson bei Windows oder coreadm bei Solaris) funktioniert: dadurch dass die HotSpot VM die Crashes selbst auswertet bekommt das Betriebsystem von den abnormalen Abstürzen nichts mit. Bei der J2EE Adapter Engine von SAP XI finden sich die Crashdumps zum Beispiel in: /usr/sap/XIx/DVEBMGS00/j2ee/cluster/server0/hs_err_*.log. Bei anderen Anwendungen bietet es sich an einfach den K-Fall einmal auszuprobieren.

Heinz Kabutz hat im Java Specialists' Newsletter #121 das Thema Vererbung behandelt. Er stellt die Frage was das theoretische und praktisch Limit für Vererbungshierachien ist. Zu Recht weist er darauf hin, dass 60 oder 1000 Hierachistufen in der Praxis nicht benutzt werden sollen. Er hat ein Programm geschrieben, das den Classpath nach Rekordhaltern absucht. Für OpenSource und kommerziellen Anwendungen möchte er Erfahrungsberichte bekommen, um den Rekord-halter "auszuzeichnen". Ich hab Ihm mal einen Hinweis auf -Xss zukommen lassen: damit dürfte er tiefer verschachtelt aufrufen, allerdings wird er dazu einen neuen Thread starten müssen, da der Main-Thread von diesem Setting nicht betroffen ist.

Es gibt eine ganze Reihe von Systemen für das Monitorring von Hard und Software. Diese haben verschiedene Schwerpunkte, wie Überwachung der Verfügbarkeit, Langzeitüberwachung von SLAs, Trendanalyse und Kapazitätsplanung. Dazu kommt dann das Thema Alerting, oder auch einfach nur eine konsolidierte Sicht auf die Systeme (Dashboard). Auch bei der Diagnose von Leistungseinbrüchen zu bestimmten Zeiten kann eine solche Datenerfassung sinnvoll sein. Bei der Erstellung von Enterprise Anwendungen sollte man also auf jeden Fall entsprechende Diagnose Schnittstellen anbieten. Leider gibt es sehr viel verschiedene Verfahren um die Werte zu exportieren. Bei Java Anwendungen hat sich die Instrumentierung mittels JMX Management Beans allerdings durchgesetzt. Das sammeln von Leistungsdaten soll die Anwendung nicht ausbremsen oder gefährden. D.h. die Daten die vorgehalten werden sollten einfach zu sammeln sein, kaum verarbeitet werden müssen und einfach im Speicher gehalten werden können. Dies schließt z.b. historische Datenreihen oder aufwändige statistische Transformationen aus. Continue reading "Application Monitoring (JMX MBean Design Patterns)"