Java Programming

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:

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.

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.

Software ist nicht perfekt und wird auch ständig weiter entwickelt. Das führt dazu, dass bestimmt Konfigurationen der Software sehr viele Generationen überleben müssen. Problem dabei ist, dass durch neue Erkenntnisse Defaults geändert werden, neue Parameter notwendig werden, und dass es eben generell schwer ist den Benutzer bei Upgrades zu unterstützen:

• Welche Parameter müssen hinzugefügt werden
• Welche Defaults haben sich geändert
• Für welche Version ist die Konfiguration

Eine gute Möglichkeit ist es einen Versions-Identifier in den Dateien mitzuführen, und bei jeder (nicht kompatibler) Änderung diesen hochzuzählen.

Anwendungen haben dann die Möglichkeit entweder den Start zu verweigern, bis das Konfigurationsfile angepasst wurde, oder sich wie die alte Version der Anwendung zu verhalten.

Welche alternative Strategien existieren? Nun eine Möglichkeit ist die Konfiguration der Anwendung zu trennen in Defaults (vom Hersteller) und Änderungen (installationsspezifisch). Damit kann der Hersteller neue Defaults ausliefern und muss nicht ermitteln welche Parameter der Anwender geändert haben möchte. Der Nachteil dabei ist allerdings, dass der Anwender sich natürlich auf bestimmte Defaults verlassen hat, und wenn diese geändert werden (typisches Beispiel: der Default für einen wenig benutzen Netzwerk Server wird von "on" auf "off" gendert. Der Anwender hatte in seiner Konfiguration die Option nicht überschrieben, da der Default ja OK war. Nach einem Update der Software kommt es zu einem Funktionalitätsverlust, weil der Benutzer nicht dazu agehalten wurde, sich über die geänderte Sematik zu informieren.

Somit bleibt so oder so nur eine ausführliche Dokumentation der Änderungen. Üblicherweise geschieht dies in Release Notes, die zu umfangreichsind um die wichtigen von den unwichtigen Informationen zu trennen. Deswegen ist für den Anwender dabei hilfreich eine Versionsnummer zu sehen, die sein File aktuell hat, die von der Anwendung erwartet wird, und welche Änderungen dazu notwendig sind.

Über den E-Mail Verteiler der Java-User-Group Stuttgart (JUGS) kam folgende Einladung rein:

Einladung zu einem
Vortrags- und Diskussionsabend
am Donnerstag, 26. Januar 2006, 18.30 Uhr
 im Hörsaal H35 der Universität Hohenheim
Wegbeschreibung: http://www.jugs.org/anfahrt-hohenheim.html
Titel: Das Java Performance Modell
Referentin: Angelika Langer

Abstract
In jeder Programmiersprache gibt es Prinzipien, die beschreiben,
wieviel Zeit ein bestimmtes Sprachkonstrukt beim Ablauf kosten wird. Diese Korrelation zwischen den Sprachmitteln und ihrer Performance bezeichnet man als Performance-Modell.

Nur damit ich den Link nicht verliere, hier eine Übersicht der Optionen die man in der SUN Java Virtual Machine findet:

blogs.sun.com/roller/resources/watt/jvm-options-list.html

Die klassische JavaHotSpot Options Beschreibung ist nicht so vollständig aber deutlich ausführlicher:

java.sun.com/docs/hotspot/VMOptions.html

Vor einiger Zeit kündigte Microsoft an, Multi-Core Prozessoren mit einer einzelnen CPU Lizenz für die Server Systeme zu besteuern. Dahinter steckt sicher die Überlegung einer einfachen Lizensierung: Server mit Multi-Core Chips haben etwa das gleiche Preisniveau wie ihre Vorgänger bei üblicher Leistungszunahme über die Zeit - keinen Grund für Microsoft Daumenschreiben anzulegen, zumal die Roadmaps von AMD und Intel nur eine langsame zunahme bei der Anzahl der Cores erkennen lassen, wobei die Schere zwischen Low und High-End Prozessoren nicht allzuweit aufklafft.

Ganz im Gegenteil jedoch im 64-bit SPARC Lager. Dort werden gleich 3 Generationen von Prozessoren weitergepflegt: UltraSPARC III, UltraSPARC IV(+), und ganz neu die auf Multi-Threading optimierten UltraSPARC T1 Prozessoren: Mit acht Cores auf einem Chip. Noch dazu hat jeder Core die Möglichkeit 4 Threads parallel zu verwalten (das von Intel bekannte Hyperthreading nennt Sun CoolThreads). Ein enormer Sprung von 1 auf 2 auf 32 Threads pro Chip.

Zur Zeit gibt es nur Single-Prozessor Systeme (Sun Fire T1000 und T2000) für den Niagara Chip. Dabei gibt es 1.0 und 1.2GHz Varianten mit 4-8 Cores. Die vier und sechs Core Varianten dürften Dies mit Defekten oder abgeschalteten Cores sein um den Ausschuss zu reduzieren und den kunden flexibles Pricing anbieten zu können.

Nun ist es so, dass die CPUs durchaus 32 Prozesse gleichzeitig ausführen können, aber durch diverse Einschränkungen keinesfalls eine 32-fache Rechenleistung bereitsteht (auch wenn Sun mit Rack-on-a-Chip oder mit "9.2GHz" wirbt). Ein 3MB L2 Cache (allerdings mit bis zu 4 SDRAM Schnittstellen), alle Threads teilen sich auch nur eine FPU. Das Chip Multi Threading stellt für jeden Thread einen Satz Register bereit, aber jede Core hat eine (6 stufige) Verarbeitungspipeline.

Ideales Workload sind somit Internet Anwendungen mit einer großen Anzahl von parallelen Threads und keinen Fliesskomma Berechnungen, die mit IO oder Memory Zugriffen beschäftigt sind. Also z.B. Web-, File oder Java Application Server. Diese profitieren wohl auch vom Hardware-RSA.

Benchmarks zeigen dass beim SPECjbb2005 Benchmark die Leistung eines T1 mit 1.2GHz 8-Core in Etwa auf Höhe eines Dual 1.9Ghz 2-Core Power5+ Moduls liegen (Betrachtet man die Zahlen, so bleibt SPARC ein eher langsamer Prozessor pro Core, sowohl im Vergleich zu den effizienten POWER5+ als auch zu den hochgetakteten Intels und Opterons) - vorausgesetzt es ist möglich mehr als 4 Opteron oder Xeon Cores zu produzieren. Aber bis dahin hat Sun extrem die Nase vorn!

Das Problem besteht aber jetzt für Software Anbieter auf Solaris Systemen: wie vergleiche ich mehrere Cores mit mehreren Prozessoren? Zuerst kam Oracle auf die Idee jede Core als 0.75 Lizenzen zu rechnen. Das kommt allerdings nur den Dual-Core Systemen entgegen. Besser wäre es sicher Systeme mit vielen Cores/Sockel zu verbilligen:

Lizenzen für eine CPU mit x cores:

l(x)=0.75^0+0.75^1+....+0.75^(x-1)

.. das wären dann 3.6 Lizensen für ein System mit einer 8 Core CPU und 7.2 Lizensen für 2x8 Cores im Gegensatz zu 3.9 Lizenzen für eine 16 Core CPU. Oder 3.5 Lizenzen für zwei Dual-Core CPUs und 4 Lizenzen für ein 4 Wege Rechner ohne Multi-cores.

Richard Monson-Haefel dürfte vielen meiner Leser als Autor der O'Reilly Bücher Enterprise Java Beans, Java Message Service oder des AW Buches J2EE Web Services bekannt sein. In seinem Blog berichtet er seit geraumer Zeit über seinen Beruf als Sr. Analyst in der Burton Group: I, Analyst.

Die Einblicke in seinen Arbeitsalltag, in die vorgeschriebene Methodik und seine Gedanken zu den Technologien sind sehr interessant. Vom Programmierer zum Generalist: man hat den Eindruck dass bei solchen Analysten die Klienten wirklich einen Mehrwert von den Analysen oder Gesprächen erwarten können.

Er plant(e) auch ein neues Buchprojekt, unter dem Arbeitstitel "This is Java" (http://rmh.blogs.com/thisisjava/) hat er eine Zeit über seine Überlegungen zu dem neuen Buch-Projekt geblogged. Inzwischen ist das Blog aber verschwunden. Schade, fand ich ein spannenden Ansatz mal die Erfolgsfaktoren von Java zu betrachten die Abseits von den üblichen Referenzwerken existieren, z.B. die Tatsache dass es einen einheitlichen Byte-Code gibt...

Update: RMH hat begonnen täglich über seinen Job zu bloggen. Er verweist auch auf das Blog von James Governors. Dieser beschreibt die Unterschiede in der Arbeit eines Analysten für die große Burton-Group im Gegensatz zur Arbeit eines Analysten fuer die kleine IT-Strategieberatung RedMonk.

Mit dem Microsoft SQL Server bin ich sehr zufrieden. Er ist ziemlich intelligent was das Selbst-Tuning angeht, gerade in einem Umfeld in dem kein Vollzeit-DBA zur Verfügung steht. Im Vergleich zu Oracle Datenbanken ist die Lernkurve deutlich geringer, Entwickler sind produktiver. Jedoch war schon immer eine Schwäche des Produktes die Unterstützung von Java (also der JDBC Treiber): der Microsoft JDBC Treiber für den SQL Server ist nur eingeschränkt frei verwendbar, die neusten Feature und Performance Verbesserungen finden sich grundsätzlich nur in Beta Versionen.

Dieses Problem haben auch einige kommerzielle Anbieter von JDBC Treibern erkannt (z.B. i-net Merlia oder JNetDirect). Wir haben in unseren Produkten lange Zeit den JSQLConnect Treiber von JNetDirect eingesetzt. Jedoch ist es für einen ISV schwer für einfache Infrastruktur Komponenten eine Beziehung mit einem Lieferanten aufrecht zu erhalten, die neben den Lizenzkosten auch Einschränkungen bei der Installation und Verteilung macht. Deswegen hat der Ablauf unseres Lizenzkontingentes und auch dazu bewogen uns nach Alternativen umzusehen.

FreeTDS stand bei uns unter Beobachtung, war aber nicht befridigend. Es ist eine Open Source Implementierung des Tabular Data Stream Protokolls, das sowohl von Sybase als auch Microsoft für die Datenbank Produkte eingesetzt wird. Erst seit der JDBC Type-4 Treiber in einem eigenen Projekt weiterentwickelt wurde, hat er sich aber als Alternative herausgestellt. jTDS ist seitdem ohne Zweifel einer der schnellste und stabilsten JDBC Treiber für den MS SQL Server, der noch dazu als Open Source (LGPL) erhältlich ist, und alle Features unterstützt die wir bisher in unseren J2EE Anwendungen (Tomcat und JBoss) benötigt haben.

Nach meiner Quizzfrage gab es einige Diskussionen über das Problem. Meine Analyse fand ein Problem im Konstruktur der Klasse Thread. Wannimmer ein Thread Objekt erzeugt wird, registriert es sich an der zugehörigen (aktuellen) ThreadGroup. Das hat den Effekt dass eine Referenz auf den Thread gehalten wird, das Objekt wird nie frei gegeben.

Gitta Zahn und Steffen Ramlov haben das Problem sofort gefunden, Stefan Matthias Aust hat darauf hingeweisen, dass aktuelle Java Versionen (1.5 und 1.6) dieses Problem nicht mehr haben, dort wird der vorbereitete Thread nicht zu einer Liste hinzugefügt. Details dazu in de.comp.lang.java.

Unabhängig davon ist es aber generell ein schlechtes Design von Thread zu erben, insbesondere wenn man plant den Thread nicht zu starten. Das Runnable Interface hat hier deutlich weniger Seiteneffekte, und man ist wesentlich flexibler mit der Erzeugung und dem Pooling der Threads.

Ich habe letzte Woche einige Zeit mit dem Eclipse Profiler verbracht, um ein merkwürdiges Memory Leak in unserer Software zu finden. Eigentlich ist das ja nicht mein Job, aber da mich der Bug von einer Kunden Demo abgehalten hat, und da ich es hasse wenn ich die Ursachen von solchen Problemen nicht kenne, habe ich ein paar Stunden meiner Freizeit im Debugger verbracht.

Problem war, dass eine unserer Komponenten sowohl synchron, als auch asynchron (mittels eigenem Thread Pool) aufgerufen werden kann. Beim synchronen Aufruf der Funktion lief aber reproduzierbar und schnell der Speicher zu. Meine Vermutung war ja erst, dass der Thread Handler am Ende der run methode noch irgendwelche cleanup tasks übernimmt, die der selten benutzte synchrone Code vergisst. Aber die Ursache ist an einer anderen Stelle, tief in der Java API zu suchen:

public class Processor extends Thread {
  public Processor() {
  }

  public void run() {
      // do something important
  }
}

public class Starter {
  public void start(boolean async) {
    Processor p = new Processor();
    if (async) {
      p.start();
    } else {
      p.run();
    }
  }
}

Na wer findet das Memory Leak bei Starter.start(false)? Auflösung im nächsten Blog Eintrag.

BTW: hat jemand eine Ahnung wie ich einfach Java Quelltext in S9Y pasten kann (am besten mit Syntax Coloring). Oder wie ich NL2BR partiell deaktivieren kann?