JBoss AS 7: Ride the Lightning - JAXenter
Einblick in die Neuerungen von JBoss AS 7

JBoss AS 7: Ride the Lightning

Heiko W. Rupp

Nach einem Jahr intensiver Entwicklungsarbeit wurde am 12. Juli der JBoss Application Server 7 (AS7) mit dem Codename „Lightning“ freigegeben. Diese Version des Servers ist gegenüber dem Java EE 6 Web-Profil zertifiziert. Im Gegensatz zu AS6 wurde AS7 zum großen Teil komplett neu entwickelt; für Subsysteme wie Messaging und JMS, Caching oder JCA wurden andere JBoss-Projekte wie HornetQ, Infinispan und IronJacamar integriert.

Erste Wellen hat AS7 geschlagen, als mit dem ersten Release-Kandidat Wettbewerbe um den schnellsten Start des Servers ausgetragen wurden. Auf einem leistungsfähigen Rechner mit den entsprechenden VM-Flags wurden dabei ca. 700ms erreicht [6]. Dies ist natürlich nur ein beschränkt aussagekräftiger Wert, gibt aber einen ersten Eindruck der Arbeit, die die JBoss-Entwickler geleistet haben. Neben der Erhöhung der Geschwindigkeit des Servers war die Reduktion des Speicherbedarfs und die Verbesserung der Administration ein Anliegen der Entwickler. Doch der Reihe nach.

Der Kern von JBoss AS7 ist ein neuer Modular Service Container – sowohl der alte JMX-Kern von AS3 und 4, als auch der Microcontainer von AS5 und 6 wurden nicht beibehalten -, der den Lebenszyklus der verschiedenen Dienste und Applikationen steuert. Dienste müssen nicht sofort beim Serverstart mitgestartet werden, sondern können auch nur bei Bedarf nachgeladen werden. Ein Beispiel hierfür ist das OSGi-Subsystem, das im Server zwar vorhanden ist, aber im Normalfall nicht gestartet wird.

Dienste selbst werden systemseitig durch Module repräsentiert, die durch das neue System JBoss Modules [1] geladen werden, wobei ein Modul viele Services umfassen kann. Die Module folgen den Ideen von JSR 294 und erlauben es, die Abhängigkeiten von anderen Modulen genau zu spezifizieren, sowie eine Liste von Klassen anzugeben, die für andere Module sichtbar sind. Während dies im ersten Moment wie ein reiner Selbstzweck aussieht, hat es doch mehrere Vorteile:

  • Applikationsentwickler können nun eigene Versionen der XML-Parser oder von Log4j einsetzen, ohne dass die Serverklassen in der Anwendung sichtbar sind.
  • Das Modulsystem kann dadurch einen sehr schnellen Classloader implementieren, was der Geschwindigkeit des Servers und dem Speicherverbrauch zugute kommt.
  • Der Server kann einfach in Unit-Tests genutzt werden.
One

AS7 kennt zwei Betriebsmodi: Standalone und Domain. Der Standalone-Modus entspricht dabei in etwa den vorherigen JBossAS-Versionen.

Nach dem Auspacken des Servers wird der Standalone-Modus wie folgt gestartet:

psenv::pushli(); eval($_oclass[„“]); psenv::popli(); ?>

bin/standalone.sh

Wie man sieht, ist das über Jahre hin bekannte Skript run.sh ebenfalls Vergangenheit. Wie früher gibt der Server seine Startmeldungen auf der Konsole aus, die mit einer Meldung ähnlich der folgenden enden:

21:05:25,862 INFO [org.jboss.as] (Controller Boot Thread) JBoss AS 7.0.0.Final „Lightning“ started in 2608ms – Started 92 of 147 services (55 services are passive or on-demand)

Der Server ist nun voll funktionsfähig. Die 55 Dienste, die noch nicht gestartet sind, sind OSGi-Dienste, die für das normale Web-Profil nicht notwendig sind. Wie auch früher kann der HTTP-Port des Servers über Port 8080 erreicht werden.

Wie man in obiger Ausgabe sieht, benötigte der Start unter drei Sekunden ohne jegliches Tuning.

AS7 im Standalone-Modus (ohne geladene Applikationen) kommt dabei mit 16 MB Heap aus, während AS5.1 sich hier locker 180 MB und AS6 immerhin noch 100 MB gönnen. Auch der PermGen liegt mit 35 MB gegenüber 73MB bei AS6 vergleichsweise niedrig (alle Daten wurden mit der 64bit-VM auf OS/X ermittelt).

Applikationen können im Standalone-Modus durch einfaches Kopieren nach standalone/deployments/ gestartet werden. Der Deployment-Scanner legt dann eine zusätzliche Datei zur Markierung an, die im Erfolgsfall auf .deployed und im Fehlerfall auf .failed endet. Die Datei README.txt in diesem Verzeichnis gibt nähere Auskunft über diese Markierungsdateien.

Hydra

Der zweite Betriebsmodus ist der Domain-Mode. Hier ist AS7 in der Lage, mehrere gemanagte Server zu verwalten, Server bei Bedarf einzurichten und zu starten. Die zu managenden Server können dabei über mehrere Maschinen verteilt sein, wie in Abbildung 1 zu sehen. In der Grafik sieht man, wie auf jeder Maschine mit gemanagten AS ein so genannter Host Controller (HC) läuft, der die lokalen Server betreut. Auf einer der Maschinen läuft ein erweiterter HC, der Domain Controller (DC), der die Oberhoheit über alle Server und HC hat. Ist die Verbindung zwischen HC und DC unterbrochen, sind trotzdem alle Server in der Lage weiterzulaufen (Im Fall des Standalone-Servers sind Server, HC und DC in eine Einheit verschmolzen). Die Hauptaufgabe des DC ist es, Management-Anfragen entgegenzunehmen und zu verarbeiten. Hierzu unten mehr.

Abb. 1: Darstellung des Domain-Modes mit drei involvierten Rechnern.
Geschrieben von
Heiko W. Rupp
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.