ITBlog

Die Java User Group Karlsruhe veranstaltet einen Vortrag über den SAP Memory Analyser, der nun Teil der Eclipse Infrastruktur ist. Als Referent wird am Mittwoch 2008-05-07 19:15 der SAP Mitarbeiter Markus Kohler den Vortrag in der Informatik Fakultät der Uni-Karlsruhe halten. Ankündigung bei Google Groups Update: ein Artikel des Referenten gibt es in der Eclipse DZone.

Wie schon im ersten Teil beschrieben, muss man trotz der Platform Unabhängikeit von Java etwas über die Zielsysteme wissen, um grobe Fehler zu vermeiden:

/** save data as UTF-8 string to file. */
saveFile(String data, File file) throws IOException, UnsupportedEncodingException {
  OutputStream out = null;
  bytes[] b = data.getBytes("UTF-8");
  try {
    out = new FileOutputStream(file);
    out.write(b);
  } catch(IOException ioe) {
    System.err.println("Cannot save data in UTF-8 to file " + file + ": " + ioe);
    throw ioe; // notify upper layer about problem
  } finally {
    silentClose(out); out = null;  // BANG, problem unterdrückt.
  }
}

silentClose(OutputStream out) {
  if (out != null)
    try { out.close(); } catch (Exception ignored) { }
}

In diesem Fall wird zwar richtigerweise im Fehlerfall der Output Stream geschlossen und die dabei eventuell auftretende Exception ignoriert, aber viel kritischer ist der Fall in dem im try block keine Exception aufgetreten ist, aber dafür dann das close() fehlschlägt. Es muss damit gerechnet werden dass im close() auf einem OutputStream eine IOException auftreten kann - sogar sehr häufig - der Grund dafür ist, dass zum einen der Stream einen flush() vor dem close() durchführen wird. Dazu kommt noch, dass die close() Methode der letzte Zeitpunkt ist, in dem ein IO Fehler gemeldet werden kann. Bei NFS ist es z.B. so, dass der client wartet bis der Server den Empfang bestätigt hat. Und dabei kann natürlich eine Menge schiefgehen. Auch quota Überschreitungen können zu einer IOException führen. Es hilft etwas als letztes Statement im try-block einen flush() durchzuführen, aber es besteht weiterhin ein Risiko dass close() fehlschlägt. Eine wichtige Regel lautet also: bei Streams in die geschrieben wird kann close() einen Fehler werfen, diese darf nicht ignoriert werden (sonst gehen Daten verloren)!

saveFile(String data, File file) throws IOException, UnsupportedEncodingException {
  OutputStream out = null;
  bytes[] b = data.getBytes("UTF-8");
  try {
    out = new FileOutputStream(file);
    out.write(b);
    out.close(); out = null;
  } catch(IOException ioe) {
    System.err.println("Cannot save data in UTF-8 to file " + file + ": " + ioe);
    throw ioe;
  } finally {
    silentClose(out); out = null;
  }
}

Im Falle von NFS ist obiger Code ausreichend. Nach dem close() ist es garantiert, dass die Daten permanent gespeichert sind. Bei lokalen Filesystemen wird diese Garantie von den gängigen Betriebsystemen NICHT gegeben. Die Daten können auch nach einem close() nur im lokalen Buffer Cache des Filesystems (RAM) liegen und erst nach einiger Zeit (typischerweise 5 Sekunden) an die Hardware Schicht übergeben werden. Dies ist zwar gut für die Performance, aber ein potentielles Fenster für Datenverlust - und eventuell Korruption des Anwendungszustandes. Wie dies zu vermeiden ist, betrachte ich im nächsten Teil (der kein Jahr auf sich warten lassen wird:)

Offener Brief von Neil Wilson (directorymanager.org) über seine Freisetzung bei Sun und den Druck der auf die (gekündigten) Project-Owner der OpenDS (LDAP Server) Community ausgeübt wurden. Wie Neil beschreibt ist das sicher ein Beipspiel für sich verselbständigendes Middle Management das den Sinn für die Realität verloren hat, aber... wieviel dieser Manager gibts bei Sun noch? (via Ben Rockwood)

Eduard Hildebrandt stellt in seinem Blog deutschsprachige Java Blogs vor. Er macht dies in Form eines Interviews. Bisher hat er drei Blogs vorgestellt, darunter auch das IT-Blog. In dem Zusammenhang habe ich noch mal über die von mir gewählte Sprache des Blogs nachgedacht, und muss sagen, ich bin immer noch nicht 100% sicher ob es eine gute oder schlechte Entscheidung war. Auf der einen Seite ist das Bloggen in Deutsch geringfügig einfacher und bedingt durch die kleinere Auswahl an Blogs wird man im eigenen Sprachraum doch schneller wahr genommen. Auf der anderen Seite jedoch habe ich viel Kontakt mit US Partnern, Kunden und Kollegen... da ist ein fachliches Blog hilfreich. Momentan liegen die Pläne das Blog zweisprachig zu führen allerdings auf Eis.

Zur Zeit klebe ich noch etwas an der Java 1.4 Version - weil sich ein konservativer Umgang mit der Nutzung von neuen Features immer als positiv zeigt. Inzwischen gibt es aber su gut wie keinen Grund mehr die Entwicklung auf Java 1.4 auszurichten. Auch die exotischten Platformen kommen inzwischen mit einem Java 5 daher. Zudem werden spührbar mehr kritische Bugs nur noch für Java 5 und Java 6 gefixed, so zum Beispiel der Berüchtigte ClassCircularityError Bug, der in Java 5.0 Update 8 endlich beseitigt wurde. Während wir also schon einige Zeit nun Java 5 als Mindestvoraussetzung haben findet Java 6 schon eine gewisse produktive Verbreitung. Deswegen hier mal wieder einen Link auf interessante Hotspot Optionen: http://www.md.pp.ru/~eu/jdk6options.html (von Eugene Kuleshov) Ich hatte solche Links ja bereits für Java 1.4 hier im Blog veröffentlicht und habe oft selbst darauf zurückgegriffen (Weblog - statt Bookmarks, ein ganz ganz altes Konzept!).

Einige meiner Punkte die ich durch die Tests der T1000 herausfinden möchte sind:

• Wie ist die IO-Performance der internen Platte
• Wie stark macht sich die geringe Takt-Frequenz bei Single-Thread Nutzung bemerkbar
• Wie gut lassen sich Java Anwendungen parallelisieren
• Wieviele Hidden Floating Point Operatione finden sich in Java

Allerdings werden Sie sich noch etwas gedulden müssen, da ich noch auf Dienstreise in Göteborg bin. Übrigens haben sich in der Zwischenzeit schon mehrere Sun Mitarbeiter gemeldet, um mich Willkommen zu heissen. Sie haben mir Pre-Sales Unterstützung angeboten, auf Resourcen hingewiesen und mich zum bloggen meiner Erfarungen auf dem Systemhelden.de Blog eingeladen. Ich habe dort jetzt auch ein HELDENProfil. Die ganze Story zum sun Try&Buy:

• Part I - Die Online Registrierung
• Part 2 - Der Sales Anruf
• Part III - Willkommen
• Part IV - Frightening Freight

Aber genug von der Arbeit, hier ein paar Impressionen aus Göteborg: Fotos aufgenommen von einer Fähre die mit 24h Nahverkerskarte (50,- SKR) als Hafenrundfahrt benutzt werden kann.

Endlich kommt von SAP wieder News zu Ihrer eigenen JVM. Vor einiger Zeit gab es ja Berichte über eine JVM die optimiert ist auf den isolierten Betrieb von Anfragen, mit einem Shared Speicher Bereich und verbesserten Management Funktionen. Das Ergbnis ist in diesem SDN Blog Artikel von Oliver Schmidt. Die Investition in Java Entwicklung scheint sich gelohnt zu haben. Hier sollte man weiterhin ein Auge drauf werfen...

• Advanced Tracing and Monitoring
• Improved Full Thread Dumo
• JIT Native Code Debugging
• Java Debugging on Demand
• Heap Dump (Markus Kohler)
• Multi Instance Support

In einem Blog Artikel beschreibt Joshua Bloch einen Bug in der binary-search Implementierung der Java Klassenbibliothek und schliesst die Ausührung mit der Bemerkung:

The binary-search bug applies equally to mergesort, and to other divide-and-conquer algorithms. If you have any code that implements one of these algorithms, fix it now before it blows up. The general lesson that I take away from this bug is humility: It is hard to write even the smallest piece of code correctly, and our whole world runs on big, complex pieces of code. We programmers need all the help we can get, and we should never assume otherwise. Careful design is great. Testing is great. Formal methods are great. Code reviews are great. Static analysis is great. But none of these things alone are sufficient to eliminate bugs: They will always be with us. A bug can exist for half a century despite our best efforts to exterminate it. We must program carefully, defensively, and remain ever vigilant.

Lesebefehl für jeden Entwickler: wird sind manchmal einfach zu arrogant und unkritisch mit unserem Code. Es geht jetzt weniger um den speziellen Fehler (ich hatte den Fehler in der Zeile vermutet aber eher bei der Rundung als beim Überlauf, und das obwohl ich normalerweise versuche solche Additionen zu vermeiden) sondern mehr um die Tatsache dass so ein trivialer Quelltext einen Fehler enthalten kann der fast 9 Jahre unbemerkt ist (und dabei Millionen von Anwendern hat, sogar in mehreren Lehrbüchern zu finden ist). Danke an Peter Luschny (de.comp.lang.java) für den Link. Dort hält man das ganze übrigens für einen PR Gag für sein neues Buch, das jetzt auch schon auf meiner Wunschliste steht.

Marc Fleury schreibt in einer Mail an Kunden und Partner:

I am writing to you today to announce that the Red Hat acquisition of JBoss has closed and we now are officially a part of the largest independent open source company. I am excited about this news and the great opportunity that it represents. We are entering a new era in the technology industry that puts customers back in charge of their destiny, where innovation and value replace lock-in and costly proprietary-vendor software licenses. Together, we believe we can change the economics of the industry, delivering unmatched value to our customers and partners by creating better software faster, systematically driving down costs and simplifying IT

B*LLSH*T. Meine Reaktion war, dass er damit in jedem Bullshit-Bingo gewinnt.

Es hat einige Zeit gedauert bis Microsoft eine Alternative für das Deployment von lokalen Anwendungen per Web Browser hatte. In der Java Welt gibt es hierfür Java Web Start, das mittels JNLP Protokoll erlaubt einen lokalen Cache zu füllen, und eine Anwendung in einer (einfachen) Sandbox auszuführen. Microsoft plaziert ClickOnce als .NET 2.0 Technology. Sie haben damit den großen Vorteil dass das Sandboxing durch die umfangreichen .NET Möglichkeiten sehr weitgehend eingestellt werden kann. Ganz im Gegensatz zum JWS, wo die Integration in den Security Manager ziemlich mager ausgefallen ist. Ich habe noch keine Erfahrung mit ClickOnce, im JWS Umfeld kenne ich das Problem, dass das Debugging und fixen von JWS Installationen sehr Support Aufwändig ist. Die JWS Implementierung des Sun JDKs ist hier nicht sonderlich gut gelungen. Wir verteilen einen Admin Client auf diese Art und Weise, und weil wir damit oftmals die ersten in einem Unternehmen sind haben wir immer wieder die Freude dysfunktionale JWS Installationen zu debuggen. Ich glaube durch die stärkere Integration hat Microsoft dieses Problem bei Ihren Installern nicht. Und es wird sicher nicht mehr lange dauern bis auch Firefox einen Mime Handler für application/x-ms-application aufweisen kann. Eventuell könnte es dann sogar Sinn machen Java Anwendungen auf diesem Weg an Microsoft Desktops zu verteilen.

Ich war ganz erleichtert, dass JBoss von RedHat gekauft wurde: Weder die großen Kommerziellen (BEA, Oracle) kamen zum Zug, noch konnte JBoss so weiterwerkeln. Bisher hatte ich aber dazu nicht wirklich was zu bloggen, hab aber bei Wolfgang Sommergut einen Verweis auf The Register gefunden:

• Wolfgang Sommergut: Marc F. über RH (von The Register)

Ebenso finden sich Posts bei RMH:

• RH aquires JBoss
• Marc: Share the Wealth!

Gerade bin ich von einem Kurztripp zurück, da muss ich doch in RMH's Blog lesen, dass er für seine Analysten-Beschäftigung die WebService Fähigkeiten der JEE5 Platform untersucht hat: JAX-WS ist fast so schlimm wie JAX-RPC. Letzteres hatte er, nachdem die Arbeiten für sein Buch J2EE Web Services abgeschlossen waren schon mit dem Prädikat "bad, bad, bad" belegt. Immerhin noch 2 bads hat er für die Nachfolgertechnologie über:

Not only is the runtime behavior, including handler chains, still complicated but the number of annotations required could make source code (end-point interfaces or implementation classes) look like 20 kids tagged it with spray cans. It will be hard to see the code through all the annotations.

Und er stellt die Sun Entwickler in die Pflicht hier etwas besseres anzubieten:

Doubt what I'm saying? Try to implement the eBay and Amazon.com web services with JAX-WS 2.0 - if it's really easy than show me and I'll eat my words. There you go JAX-WS 2.0 team: A challenge! You guys ought to be ashamed of yourselves. You could have taken this opportunity to re-engineer J2EE web services into something really simple, but you decided to put lipstick on the Pig instead.

Stellt sich natürlich die Frage nach den Alternativen... welche WebService Libraries setzten Sie ein?

Weil ich nebenbei dran bin das Thema IT-Sicherheit im Software Entwicklungsprozess aufzubereiten, hier eine Liste von möglichen Motivationspunkten. Wovor soll geschützt werden...

• Das Image eines Software Unternehmens ist sehr wichtig. Vertrauen in die Beständigkeit und Leistungsfähigkeit des Softwarehauses ist eines der wichtige Auswahlkriterien bei der Beschaffung von Software..
• Zumindest in Deutschland kann sich ein Unternehmen nicht aus der Produkthaftung befreien. Auch bei Auftragsarbeit besteht das Risiko von Regressansprüchen
• Für bestimmte Einsatzbereich fordern Kunden Explizit Audits und Zertifizierungen des Entwicklungsprozesses. In bestimmten Bereichen wird dies auch durch Gesetzgeber oder Verwaltung gefordert. Compliance ist ein wichtiges neues Thema.
• Software Unternehmen sind der Prototyp eines IT-lastigen Unternehmens. Entsprechend wichtig ist ein Securitymanagement in diesem Bereich.
• Die IT gilt zwar gemeinhin als Rationalisierungsmittel, Software Hersteller und Beratungshäuser sind aber extrem personalintensive Dienstleistungsunternehmen. Der Faktor Mensch im Prozess bringt aber einige Probleme mit sich. Von personenbezogenen Daten über irrationales Verhalten (und der Herausforderung der Führung) bis hin zu den unvermeidlichen Fehlern.
• Unternehmen mit hohem Anteil an F&E stehen unter verstärkter Wettbewerbsbeobachtung bis hin zur Industriespionage. Der Schutz von Intellectual Property wird oft als wichtiger Überlebensfaktor angesehen. Mit den drohenden Softwarepatenten wird diese Situation nur schlimmer.
• Der Trend zur Software aus dem Regal (COTS) existiert auch in sicherheitskritischen Bereichen. Als Softwarehersteller kann man sich hier schnell in der Verantwortung finden. Menschenleben oder Menschenrechte können von der ordnungsgemäßen Funktion der Software abhängen.

Diese Gründe sprechen dafür der IT-Sicherheit im Entwicklungsprozess und im fertigen Produkt verstärkte Aufmerksamkeit zukommen zu lassen. Es gibt allerdings auch Herausforderungen zu meistern sind: Continue reading "Sicherheit im Entwicklungsprozess"

Bei AMD64DevX gibt es einen zweiteiligen Artikel (P1, P2) zur Konfiguration von LargePages für Java. Dabei wird für die BEA, IBM und Sun VM beschrieben wie Anwendungen mit großem Heap dieses Betriebsstem Feature (bei Linux und Windows) nutzen können. Am Ende des Artikels findet sich einen Verweis auf das AMD's CodeAnalyst performance analyzer der es ermöglicht genau zu sehen wieviele TLB Cache Misses die Anwendung für die Datensegmente noch hat.

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.