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.