WildFly 16 released!

Seit gestern steht die Version 16.0.0.Final des WildFly zum Download bereit (http://wildfly.org/downloads/).

Bei einem kurzen Blick darauf sind mir zwei interessante Neuerungen aufgefallen:

  • Der Server unterstützt nun auch Microprofile Metrics.
  • Mit Hilfe von Galleon (https://github.com/wildfly/galleon), einem neuen Provisionierungstool, können Serverinstallationen erzeugt werden, die nur die jeweils benötigten Module enthalten.

Beide Punkte zeigen, dass der Server sich immer weiter in Richtung Cloud Readiness entwickelt.

Bis bald – vielleicht auch in einem unserer Trainings in Berlin, Bielefeld, Köln oder bei Ihnen!
https://gedoplan-it-training.de/

Werbeanzeigen

Rightsize your Services mit WildFly Swarm

WildFly Swarm

Überblick

Klassische Application Server wie JBoss/WildFly oder Glassfish/Payara sind etablierte und ausgereifte Ablaufumgebungen für Enterprise-Applikationen. Dass mehrere Anwendungen bis zu einem gewissen Grade voneinander isoliert in einem Server berieben werden können, wird in der Praxis wegen der unvermeidlichen Gemeinsamnutzung von Java VM, CPU, Memory etc. selten ausgenutzt. Man trifft also meist Server an, auf denen genau eine Anwendung deployt ist. Durch den Trend zu Microservices kommt es zu einer deutlichen Vergrößerung der Serveranzahl mit den daraus resultierenden Anforderungen im Bereich Installation, Konfiguration und Betrieb. Populäre Alternativen zu Java EE – z. B. Spring und Dropwizard – nutzen ein anderes Betriebsmodell: Statt Anwendungen in jeweils einen Server zu deployen, wird der Server in die Anwendungen integriert. Für die Java-EE-Welt bietet das Open-Source-Projekt WildFly Swarm (wildfly-swarm.io>) einen solchen Ansatz.

Komposition der Runtime

WildFly Swarm ist vergleichbar mit einem in Stücke zerteilten WildFly Application Server. Diese Stücke – sog. Fractions – werden als Maven Dependencies zur Anwendung hinzugefügt:

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>org.wildfly.swarm</groupId>
      <artifactId>bom-all</artifactId>
      <version>${version.wildfly.swarm}</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

<dependencies>
  <dependency>
    <groupId>org.wildfly.swarm</groupId>
    <artifactId>jaxrs-cdi</artifactId>
  </dependency>
  <dependency>
    <groupId>org.wildfly.swarm</groupId>
    <artifactId>jpa</artifactId>
  </dependency>
  ...

Die derzeit (Dez. 2016) aktuelle Version ist 2016.12.0.

Aus den so gewählten Fractions und dem eigentlichen Anwendungscode wird dann ein Uber Jar gebaut. Dies geschieht mit Hilfe eines Plugins in der Maven-Konfiguration des Projektes:

<build>
  <plugins>
    <plugin>
      <groupId>org.wildfly.swarm</groupId>
      <artifactId>wildfly-swarm-plugin</artifactId>
      <version>${version.wildfly.swarm}</version>
      <configuration>
        <mainClass>de.gedoplan.micro.bootstrap.SwarmBootstrap</mainClass>
      </configuration>
      <executions>
        <execution>
          <goals>
            <goal>package</goal>
          </goals>
        </execution>
      </executions>
    </plugin>
  </plugins>
</build>

Die o. a. Main Class dient der programmatischen Konfiguration der Anwendung (s. u.). In einfachen Fällen wird sie nicht benötigt. Das entsprechende Element der Plugin-Konfiguration entfällt dann.

Durch den Build-Lauf (z. B. per mvn package) entsteht dann im target-Verzeichnis neben dem normalen Zielartefakt xyz.war eine Datei namens xyz-swarm.jar, die die Anwendung inkl. Server Runtime enthält.

Konfiguration der Anwendung

Wenn die Default-Konfiguration nicht ausreicht, weil bspw. DB-Verbindungen eingerichtet werden müssen, kann eine individuell prgrammierte Main-Klasse genutzt werden. Darin können die einzelnen Fractions mit Hilfe eines Fluent API parametrisiert werden. Alternativ kann eine externe Konfigurationsdatei referenziert werden:

public class SwarmBootstrap {

  public static void main(String[] args) throws Exception {
    Swarm swarm = new Swarm();

    System.setProperty("swarm.context.path", "micro-ohne-server");

    URL standaloneFullXml = SwarmBootstrap.class.getClassLoader().getResource("configuration/standalone-full.xml");

    swarm
        .withXmlConfig(standaloneFullXml)
        .start()
        .deploy();
  }

Die im Beispiel genutzte externe Konfigurationsdatei entspricht der vom WildFly Application Server bekannten standalone-full.xml, muss aber nur die für die zu konfigurierenden Fractions benötigten Einstelldaten enthalten.

Anwendungsstart

Die Anwendung wird durch Ausführung des durch das o. a. Plugin erzeugte Uber Jar gestartet: java -jar target/xyz-swarm.jar.

Weitere Infos

Wildfly mit http/2

Unter der „vielsagenden“ Spezifikation rfc7540 wurde mitte letzten Jahres die Version 2 des http-Protokolls verabschiedet. Basierend auf Googles eigener Entwicklung „SPDY“ verspricht der neue Standard schnellere Webseiten. Grund genug einen Blick auf die Möglichkeiten zur Integration in unsere Java EE Landschaft zu werfen und die Frage zu stellen „Was bringt es wirklich“?

Die Änderung des Protokolls von http/1.1 auf die Version 2.0 Bedarf grundsätzlich erst einmal keinerlei Änderungen innerhalb der Anwendungen. Es geht lediglich darum wie der Browser und der Webserver miteinander kommunizieren. Bis zur Version 1.1 sah das in aller Regel so aus das für das Laden einer vollständigen Webseite eine Vielzahl an einzelnen TCP-Verbindungen zu ein und demselben Host geöffnet wurden um HTML, JavaScript, CSS und Bild-Dateien vollständig zu laden. Zum Aufbau jeder dieser Verbindungen (maximal 6-8 Verbindungen parallel pro Host) waren gewisse Header-Informationen notwendig die im Text-Format wiederholt über die Leitung transportiert werden mussten. Um dieser Probleme Herr zu werden geht http/2 in mehreren Punkten neue Wege:

  • Multiplexing
    • Mehrere Request über eine TCP-Verbindung
  • Header Compressing
    • Komprimierung der Header-Informationen
  • Server-Push
    • Empfangen von Ressourcen die noch nicht angefordert wurden

Ob die eigene Anwendung nun von diesen neuen Features profitiert hängt stark von der Anwendung selbst ab und in welchem Maße bereits Optimierungen für http/1.1 durchgeführt wurden. Generell kann man sagen das Anwendungen die viele kleine Requests durchführen stärker von der neuen Version profitieren als Anwendungen die wenige aber dafür große Requests verwenden.

Wildfly, ready for take off!

Ab Wildfly 9 wird http/2 im JBoss unterstützt. Leider reicht zur Nutzung ein einfaches Aktivieren über die Console nicht aus. Bis Java 9 veröffentlicht wird benötigen wir für unser JDK 8 eine Erweiterung die wir den Java-Options unseres Servers hinzufügen: ALPN. Dabei ist auf die korrekte Version zu achten die sich aus der verwendeten Java-Version ergibt, (s. „Versions“ unter: http://www.eclipse.org/jetty/documentation/current/alpn-chapter.html ). Das korrekte JAR muss dann als zusätzlicher Start-Parameter bereitgestellt werden, hier zum Beispiel über die standalone.conf.bat:

set "JAVA_OPTS=%JAVA_OPTS% -Xbootclasspath/p:%JBOSS_HOME%/bin/alpn-boot-8.1.3.v20150130.jar"

Darüber hinaus ist http/2 in den meistens Browsern nur über eine gesichterte Verbindung möglich, aus dem Grund fügen wir unserem Server eine entsprechende Konfiguration hinzu. Für die lokale Entwicklung können die Zertifikate selbst generiert werden und der Keystore im „configuration“ Ordner des Wildfly’s abgelegt werden:

keytool -genkey -alias server -keyalg RSA -keystore https.keystore

standalone.xml

<security-realm name="HTTPSRealm">
    <server-identities>
        <ssl>
            <keystore path="https.keystore" relative-to="jboss.server.config.dir"
keystore-password="123456" alias="server" key-password="123456"/>
        </ssl>
    </server-identities>
</security-realm>

Zu guter Letzt fügen wir nur einen entsprechenden HTTPS-Listener mit aktiviertem http/2 hinzu:

<https-listener name="https" socket-binding="https" security-realm="HTTPSRealm"
enable-http2="true"/>

Früher war alles Besser…oder?

Wie bereits angesprochen hängt der eigentliche Performance Gewinn von der eigenen Anwendung ab. Hier ein sehr einfaches Beispiel das bewusst sehr viele einzelne Requests abfeuert um auch bei der gezeigten Verbindung mit der lokalen Entwicklungsmaschine ein aussagekräftiges Ergebnis zu liefern:

http_v1

http_v2

Drei Dinge fallen auf: Die Übertragene Datenmenge pro Request unterscheidet sich, http/2 erreicht durch die Komprimierung von Kopf-Information eine Minimierung der Datenlast. Die Anzahl der Verbindungen zum Server selbst (Spalte 5) macht deutlich das http/2 hier wirklich nur eine einzelne Verbindung zum Server offen hält und damit nicht nur die Datenmenge reduzieren kann sondern auch den Server entlastet. Insgesamt zeigt die Zeitmessung von Chrome das die http/2 Variante auch in unserem sehr kleinen Beispiel zumindest ein wenig schneller ist. Das Beispiel lief nun auf einem lokalen Entwicklungsrecher bei dem die Antwortzeiten zwischen Browser und „localhost“ Erwartungsgemäß gering sind, ein Beispiel über ein echtes Netzwerk (mit realistischen RTT) würde in diesem Fall noch deutlicher ausfallen.

Ob sich http/2 nun für die eigenen Anwendungen lohnt oder nicht kann pauschal nicht beantwortet werden, je nachdem wie die eigene Anwendung aufgebaut ist kann es aber zu spürbaren Verbesserungen führen. Die Unterstützung durch die Browser ist umfassend (IE ab Version 11), also worauf warten wir noch?

 

 

WildFly 8 – erste Erfahrungen

Die Mitte Februar veröffentlichte finale Version des Java-EE-7-Servers WildFly nutzen wir seitdem für einige interne Projekte und unsere Seminare. Die Erfahrungen sind bislang recht gut. Eine Migration von JBoss AS 7 ist in allen Fällen ohne Probleme möglich gewesen. Die herausstechenden neuen Eigenschaften sind:

  • Der Web Container wurde komplett ausgetauscht. Statt dem bisherigen JBoss Web (~Tomcat-Fork) werkelt nun Untertow an dieser Stelle. Er ermöglicht u. A. das Upgrading von HTTP-Verbindungen in andere Protokolle, so dass die diversen Dienste des Servers fortan über den HTTP-Port (8080 im Default) abgewickelt werden können. Es werden also nur noch 2 Ports für die administrativen und normalen Zugänge benötigt statt dem knappen Dutzend der Vorversionen. Darüber hinaus bietet Undertow natürlich u. A. Websocket-Unterstützung (ist ja im Standard) und non-blocking I/O.
  • Role Based Administration: Waren administrative User bislang allmächtig (zumindest was den Server angeht …), so lassen sich jetzt verschiedene Administrationsrollen definieren, um die Rechte der Administratoren auf den von ihnen benötogten Umfang anzupassen.

Für den produktiven Einsatz wird man sicher noch die nächsten Minor-Versionen abwarten wollen. Beim Bugfixing ist die Entwicklergemeinde derzeit sehr rege, so dass das nicht allzu lange auf sich warten lassen wird.

Unser Kurs „Entwicklung und Betrieb von Anwendungen auf WildFly 8“ (http://gedoplan-it-training.de/java-grundkurse/entwicklung-und-betrieb-von-anwendungen-auf-wildfly-8/) gibt Administratoren und Entwicklern einen umfassenden Einblick in den Betrieb des neuen Servers.

Active session count in JBoss EAP / WildFly

JBoss EAP / WildFly gathers a lot of statistics of the deployed applications including the number of active (web) sessions. Unfortuntely this figure is not accessible by the adminstration console (yet?), but you can look it up with JBoss CLI. As an example, if you have

  • a managed domain with a host named master and a server named m0
  • an enterprise application named showServer-ear.ear which contains a web application (name does not matter)

you can get the active session count of the web application by issuing the following JBoss CLI command:

/host=master/server=m0/deployment=showServer-ear.ear/subdeployment=*/subsystem=web:read-attribute(name=active-sessions)

See you at one of our next Java EE Workshops:
Java EE 6/7 Hands-On Workshop, 14-03-2014 in Berlin,
Power Workshop Java EE 6/7, 27-01-2014 – 31-01-2014 in Berlin or 03-03-2014 – 07-03-2014 in Bielefeld