"memtest86+" - meine Rettung...

Diese Woche hatte ich zahlreiche Schreckminuten - eine Kernelpanic nach der nächsten... obwohl genau diese Konfiguration eine Uptime von >450 Tagen hatte und immer problemlos funktioniert hat.

Ich habe den Linux-Kernel des Hosts auf meinem VServer-System getauscht (von 2.6.22.18 auf 2.6.26.2) und auch das Update von Debian "Etch" nach "Lenny" vollzogen.

Stutzig wurde ich als der neue Kernel auch ein "Segfault" nach dem nächsten (verschiedene!) meldete...

Ein "memtester"-Aufruf im laufenden Betrieb unter Linux brachte sehr schnell eine Kernelpanic... Ein memtest86+ bestätigte meine Vermutung: Nach wenigen Sekunden hatte memtest86+ schon RAM-Fehler festgestellt (im Bereich um 305MB).

Nach dieser Erkenntnis habe ich den ersten RAM-Riegel ausgebaut und den 2ten in die erste Bank gesteckt. Dann nochmal einen memtest86+ und einen memtester unter Linux gemacht - alles ohne Probleme. Jetzt läuft mein Server wieder mit mageren 1000MB RAM - aber er läuft wieder.

Fazit: Auch wenn man Markenspeicher eines renommierten Herstellers verwendet kann es nach 3-4 Jahren auch zu Problemen kommen - oder die Staubschicht auf dem RAM und der RAM-Bank war etwas zu hoch ;)

Und zum Abschluss noch ein Kernel-Zitat:
"Eeek! page_mapcount(page) went negative! (-1)".

Tip: Firefox unter Linux und Backspace

Wer mal einen Windows-Benutzer an seinem Linux-Rechner gesehen hat (ja die soll es ja auch noch vereinzelt geben) dem fällt evtl. das Firefox/Backspace-Problem auf. Der Windows-Firefox-Benutzer drückt häufiger die Backspace-Taste und erwartet anscheinend den Sprung auf die vorige Seite.

Das ist per Default in der Linux-Variante des Firefox-Browsers deaktiviert. Aktiviert werden kann dieses Verhalten in "about:config" unter "browser.backspace_action". Hier einfach den Wert "0" (anstatt "2" oder >1) eintragen und fertig.

Weitere Informationen:

• "browser.backspace_action" im Mozilla Wiki

Tip: Tomcat 5.x Encoding-Problematik...

Das Encoding-Problem ist wohl vielen bekannt - ich wollte mir auch schon ein "Schei* Encoding" T-Shirt bestellen...

Im Apache Tomcat 6 reichte bei mir immer ein

request.setCharacterEncoding("UTF-8");

bei folgendem Seitenkopf in der JSP

<%@ page pageEncoding=”UTF-8″ contentType=”text/html; charset=UTF-8″%>

und ich konnte die Anfrageparameter in UTF-8 ohne Probleme auslesen.

Natürlich sollte man das wie z.B. im Spring-Framework wenn möglich in einen eigenen Servlet-Filter (siehe CharacterEncodingFilter) auslagern.

Beim Tomcat 5.x hatte ich mit diesem Vorgehen leider kein Glück. Weder die Context-Konfigurationsoptionen "URIEncoding" noch "useBodyEncodingForURI" in der Konfigurationsdatei brachten Besserung. Dieses Problem hatten aber wohl schon mehrere Anwender - siehe hier.

Bisher konnte ich das Problem leider nur auf folgendem Weg lösen:

String firstname = request.getParameter("firstname");
if (firstname != null) {
    firstname = new String(firstname.getBytes("ISO-8859-1"),"UTF-8");
}

In diesem Fall konvertiere ich den Parameter von "ISO-8859-1" nach "UTF-8". Das sollte laut Tomcat FAQ auch kein Problem darstellen, da das Default-Encoding bei Servlets laut dem FAQ auch "ISO-8859-1" sein sollte:

Default Encoding for POST

ISO-8859-1 is defined as the default character set for HTTP request and response bodies in the servlet specification (request encoding: section 4.9 for spec version 2.4, section 3.9 for spec version 2.5; response encoding: section 5.4 for both spec versions 2.4 and 2.5). This default is historical: it comes from sections 3.4.1 and 3.7.1 of the HTTP/1.1 specification.

Update 14.07.2009: Ich konnte mit folgender Testseite alle drei Tomcat-Versionen:

• 5.0.28
• 5.5.27
• 6.0.20

erfolgreich testen. Bei allen Versionen ergab der Test das gleiche Verhalten. Meine Encoding-Testseite funktionierte problemlos wenn nicht vor dem "setCharacterEncoding" ein Anfrage-Parameter abgefragt wurde.

Wirklich komisch - ich muss nochmal genau nachforschen warum das ältere Projekt im Tomcat 6.x problemlos mit dieser Variante funktionierte und bei Tomcat 5.x Probleme bereitet hatte.

Update 15.07.2009: Das Rätsel ist gelöst! eine jar-Datei hat zu diesem Phänomen bei dem alten Projekt geführt. In meinem Fall eine jar-Datei des CMS FirstSpirit namens "fs-access.jar". Wenn diese aus dem "WEB-INF/lib"-Verzeichnis entfernt wird und "setCharacterEncoding" verwendet wird funktioniert auch im Tomcat 5.x alles wie erwartet. Evtl. ist die "fs-access.jar" in diesem Fall eine veraltete Version. Warum der Tomcat 5.x damit ein Problem hat und der Tomcat 6.x nicht ist mir aber immer noch ein Rätsel.

Update 15.07.2009 / 2: Die Kontext-Konfiguration "URIEncoding" wirkt sich nur auf das URI-Encoding aus! d.h. das muss verwendet werden wenn man die Parameter z.B. im Querystring übergibt (HTTP-Methode GET). Wenn das in der server.xml konfiguriert wurde kann man sich das Umwandeln von "ISO-8859-1"-Zeichenfolgen nach "UTF-8" sparen.

Weitere Informationen:

• utf-8 in java webapplikationen
• Tomcat Wiki UTF-8
• Tomcat Character Encoding FAQ