WildFly 10.1 new features

User Rating: 5 / 5

Star ActiveStar ActiveStar ActiveStar ActiveStar Active

WildFly 10.1 has been released. Let's see which are the most significant enhancements introduced in the application server.

New load-balancing profile

One of the new features available since WildFly 9, is the ability to act as a mod_cluster based front­end for your back­end applications. This will remove the need to use a native Web server like Apache (and mod_cluster libs installed on it) as load balancer to a cluster of WildFly servers.

Here is a sample view of a cluster of WildFly backend servers fronted by a WildFly frontend server configured to route request using the Mod_cluster Management Protocol (MCMP):

WildFly 10.1 new features

With configurations prior to WildFly 10.1 you needed to create an Undertow filter in your configuration which filters traffic to the advertise socket binding of mod_cluster. Now the application server ships out of the box with a configuration named standalone-load-balancer.xml which is a minimal WildFly Web server configuration that can be used as front end, instead of Apache Web server:

<subsystem xmlns="urn:jboss:domain:undertow:3.1">
    <buffer-cache name="default"/>
    <server name="default-server">
        <http-listener name="default" socket-binding="http" redirect-socket="https" enable-http2="true"/>
        <http-listener name="management" socket-binding="mcmp-management" enable-http2="true"/>
        <host name="default-host" alias="localhost">
            <filter-ref name="load-balancer"/>
    <servlet-container name="default"/>
        <mod-cluster name="load-balancer" management-socket-binding="mcmp-management" advertise-socket-binding="modcluster" enable-http2="true"/>

If you are using Domain mode there is a corresponding load-balancer profile which can be used for the same purpose:

<profile name="load-balancer">
 . . .

Built-in HTTP/2 capabilities

HTTP/2 is the new version of the HTTP /1.1 protocol. It improves the communication in many aspects: first of all it's binary, instead of textual. Binary protocols are far more efficient to parse, more compact “on the wire”, and less error prone. Also HTTP/2 is fully multiplexed. Multiplexing addresses allows multiple request and response messages to be routed at the same time; it’s even possible to mix parts of one message with another on the wire.

HTTP/2 also requires a TLS security stack, therefore in order to use it you had to exploit a complex procedure in order to enable the application server's JVM to use it.

This is not needed anymore as by default the application server ships with an https-listener that is capable of using HTTP/2:

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

A demo certificate has been installed and configured in the ApplicationRealm:

<security-realm name="ApplicationRealm">
                <keystore path="application.keystore" relative-to="jboss.server.config.dir" keystore-password="password" alias="server" key-password="password" generate-self-signed-certificate-host="localhost"/>
            <local default-user="$local" allowed-users="*" skip-group-loading="true"/>
            <properties path="application-users.properties" relative-to="jboss.server.config.dir"/>
            <properties path="application-roles.properties" relative-to="jboss.server.config.dir"/>

You can try starting the application server and you will notice that the self-signed certificate has been created for you:

15:53:55,896 WARN  [org.jboss.as.domain.management.security] (default I/O-2) WFLYDM0113: Generated self signed certificate at /home/francesco/jboss/wildfly-10.1.0.Final/standalone/configuration/application.keystore. Please note that self signed certificates are not secure, and should only be used for testing purposes. Do not use this self signed certificate in production.
SHA-1 fingerprint of the generated key is 51:99:b6:42:d4:cc:41:bc:66:68:bd:5f:47:fe:e3:c7:da:8d:b0:ad
SHA-256 fingerprint of the generated key is 51:58:18:fb:16:33:8f:90:eb:31:d9:79:de:77:78:2b:c0:ed:56:af:b2:00:6a:20:e5:62:c5:ac:09:24:3c:f3

You can verify that the HTTP/2 protocol is active by pointing the browser to a secure port (ex. https://localhost:8443). The response is then “HTTP/2.0” something and Firefox inserts its own header called “X­Firefox­Spdy:” as shown in the screenshot below:

WildFly 10.1 new features

Enable Clustering on MS Azure

WildFly 10.1 now by default include support, at JGroups level, for Azure Cloud service. This is not included in the default profile of the server, but you will find a demo configuration in the JBOSS_HOME/docs/examples/configs/standalone-azure.xml. Here is the relevant configuration which instead of the default JGroups' PING protocol has the azure.AZURE_PING protocol:

        <stack name="udp">
            <transport type="UDP" socket-binding="jgroups-udp">
                <property name="ip_mcast">false</property>
            <protocol type="azure.AZURE_PING">
                <property name="storage_account_name">${jboss.jgroups.azure_ping.storage_account_name}</property>
                <property name="storage_access_key">${jboss.jgroups.azure_ping.storage_access_key}</property>
                <property name="container">${jboss.jgroups.azure_ping.container}</property>
            <protocol type="MERGE3"/>
            <protocol type="FD_SOCK" socket-binding="jgroups-udp-fd"/>
            <protocol type="FD"/>
            <protocol type="VERIFY_SUSPECT"/>
            <protocol type="pbcast.NAKACK2">
                <property name="use_mcast_xmit">false</property>
                <property name="use_mcast_xmit_req">false</property>
            <protocol type="UNICAST3"/>
            <protocol type="pbcast.STABLE"/>
            <protocol type="pbcast.GMS"/>
            <protocol type="UFC"/>
            <protocol type="FRAG2"/>
        <stack name="tcp">
            <transport type="TCP" socket-binding="jgroups-tcp"/>
            <protocol type="azure.AZURE_PING">
                <property name="storage_account_name">${jboss.jgroups.azure_ping.storage_account_name}</property>
                <property name="storage_access_key">${jboss.jgroups.azure_ping.storage_access_key}</property>
                <property name="container">${jboss.jgroups.azure_ping.container}</property>
            <protocol type="MERGE3"/>
            <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/>
            <protocol type="FD"/>
            <protocol type="VERIFY_SUSPECT"/>
            <protocol type="pbcast.NAKACK2"/>
            <protocol type="UNICAST3"/>
            <protocol type="pbcast.STABLE"/>
            <protocol type="pbcast.GMS"/>
            <protocol type="FRAG2"/>

Simply start the application server including the correct values for the System Properties. ex:

$ ./standalone.sh -Djboss.jgroups.azure_ping.storage_account_name="A" -Djboss.jgroups.azure_ping.storage_access_key="B" -Djboss.jgroups.azure_ping.container="C"

Upgrading existing JGroups configurations

If you want to upgrade an existing WildFly configuration to use AZURE_PING, just execute the following batch script which removes at first the default MPING protocol and then adds the azure.AZURE_PING protocol to the TCP JGroups stack: