JBoss EAP6 High Availability: From the basic uses of JBoss EAP6 through to advanced clustering techniques, this book is the perfect way to learn how to achieve a system designed for high availability. All that's required is some basic knowledge of Linux/Unix.

The clustering for a web server may be the most popular topic and is well understood by the majority. There are a lot of good solutions in the market.

For JBoss EAP6, the solution it adopted is to use Apache httpd as the load balancer. httpd will dispatch the user requests to the EAP server. Red Hat has led two open source projects to work with httpd, which are called mod_jk and mod_cluster . In this book we'll learn how to use these two projects.

JBoss EAP6 has provided the @org.jboss.ejb3.annotation.Clustered annotation that we can use on both the @Stateless and @Stateful session beans.

When using @Clustered with @Stateless, the session bean can be load balanced; and when @Clustered is used with the @Stateful bean, the state of the bean will be replicated in the cluster.

JBoss EAP6 provides two web service solutions out of the box. One is JBossWS and the other is RESTEasy. JBossWS is a web service framework that implements the JAX-WS specification. RESTEasy is an implementation of the JAX-RS specification to help you to build RESTFul web services.

HornetQ is a high-performance messaging system provided by the JBoss community. The messaging system is designed to be asynchronous and has its own consideration on load balancing and failover.

In the database and transaction management field, high availability is a huge topic. For example, each database vendor may have their own solutions on load balancing the database queries. For example, PostgreSQL has some open source solutions, for example, Slony and pgpool, which can let us replicate the database from master to slave and which distributes the user queries to different database nodes in a cluster.

In the ORM layer, Hibernate also has projects such as Hibernate Shards that can deploy a database in a distributed way.

JGroups and JBoss Remoting are the cornerstone of JBoss EAP6 clustering features, which enable it to support high availability. JGroups is a reliable communication system based on IP multicasting.

JBoss Remoting is the underlying communication framework for multiple parts in JBoss EAP6.

The domain mode is a new concept introduced in EAP6. A domain means a group of servers that can share configuration/deployment information, which is very useful in a clustering environment.

For example, we have the three JBoss EAP6 servers running, and they form a cluster. Suppose we have a project called cluster-demo and want to deploy it to the cluster. The traditional method is to deploy this project to each EAP6 instance manually.

Fortunately, with the help of the domain management function in EAP6, we can now configure many EAP6 servers as a server group and deploy a project into this group. Then the project will be deployed into all the EAP6 servers that belong to this group. The domain mode provides a centralized management point to our cluster. The server group also shares the same configuration that is automatically distributed to all nodes. We'll see its usage in later chapters.

The standalone mode is like the traditional JBoss AS running mode, and it doesn't have any domain management features supported during runtime.

We can see several important things from the server output. The following is the first one:

Started 123 of 177 services (53 services are passive or on-demand)

From the previous log, we can see that not all the components are started during the EAP6 startup process. This design greatly speeds up the startup time of EAP6. We can see that some services are started by default during the start process:

These components are called subsystems. These subsystems are configured in the standalone.xml file upon navigating through standalone/configuration.

Now let's see the actual command in standalone.sh that starts the EAP6 server:

eval \"$JAVA\" -D\"[Standalone]\" $JAVA_OPTS \
     \"-Dorg.jboss.boot.log.file=$JBOSS_LOG_DIR/server.log\" \
     \"-Dlogging.configuration=file:$JBOSS_CONFIG_DIR/logging.properties\"   \
     -jar \"$JBOSS_HOME/jboss-modules.jar\" \
     -mp \"${JBOSS_MODULEPATH}\" \
     -jaxpmodule "javax.xml.jaxp-provider" \
org.jboss.as.standalone \
     -Djboss.home.dir=\"$JBOSS_HOME\" \
-Djboss.server.base.dir=\"$JBOSS_BASE_DIR\" \
     "$SERVER_OPTS" "&"

From the previous command, we can see that jboss-modules.jar is the bootstrap JAR file for the whole EAP6 server, and the entry point is org.jboss.as.standalone, which is specified in the following command:

-jar \"$JBOSS_HOME/jboss-modules.jar\" org.jboss.as.standalone

We'll see more details about the startup process later. Now let's check the configuration file of the standalone mode.

The structure of standalone.xml is as follows:

As shown in the previous screenshot, standalone.xml defines multiple aspects of the standalone service. Let's have a brief view:

Besides the default file standalone.xml, EAP6 has provided some other profiles for the standalone mode.

We can check them in the standalone/configuration directory:

These files define the different profiles for different purposes. The following is a summary of their differences:

To use these alternative configurations during startup, we can use the -c option when calling standalone.sh. For example, if we want to use standalone-ha.xml, the command is as follows:

$ ./standalone.sh -c standalone-ha.xml

Please note that the -c option assumes that the configuration is located at $JBOSS_HOME/standalone/.

Both standalone.sh and domain.sh provide us with the help document. We can always use the --help option to check it:

$ standalone.sh --help

In the bin directory, there are several configuration files that will be included during the startup process:

We can put our own configuration into these files, and it will be included by the startup scripts.

As we have seen previously, when EAP6 is running in the domain mode, multiple severs can run at the same time. In addition, these servers can belong to different server groups. The servers that belong to the same group will share the deployment and configuration information.

For example, we have a server group called the main-server-group , and in this group, we have two servers called server- one and server-two . If we deploy a project called cluster-demo.war in the main-server-group, then it will be deployed into both the servers at the same time. And if we change some settings in this group, the settings of these two servers will all get synced:

In the previous example the two servers of the same group are in the same machine and the same EAP6 instance. But actually they can exist in different EAP6 servers, and the servers in the same group can be synced across the network.

Unlike the standalone mode, the domain mode uses two configuration files:

These configuration files are in the location domain/configuration/. Now let's have a look at dom ain.xml first.

The domain.xml file

The structure of the domain.xml file and its difference with standalone.xml are shown in the following screenshot:

If we compare its structure with the standalone mode, we can see the differences. Firstly there are three sections in plural form:

• profiles

• interfaces

• socket-binding-groups

The reason for this difference is easy to guess. In the domain mode, there are multiple servers running in different server groups, and EAP6 supports each server group to have its own set of settings. So, different profiles, interfaces, and socket-binding-groups will be needed.

In addition, we can see a new section called server-groups. Here is its default setting in domain.xml:

<server-groups>
  <server-group name="main-server-group" profile="full">
  <socket-binding-group ref="full-sockets"/>
</server-group>
<server-group name="other-server-group" profile="full-ha">
  <socket-binding-group ref="full-ha-sockets"/>
  </server-group>
</server-groups>

The previous settings are shown in the following figure:

In this way, different server groups are bound to different settings.

The host.xml file

Now let's check host.xml. The following screenshot shows its structure:

The host.xml file is the setting file for the host controller. It has some parts similar to standalone.xml such as management and interfaces. Their purposes are also the same. Now let's see the domain-controller section.

The domain-controller section

The domain-controller section defines which host is used as the domain controller. The domain controller is actually a host controller, but it acts as the manager of the domain. The default domain-controller is set to local, which means EAP6 will use its host controller as its domain controller by default.

We can also define a remote host controller as the domain controller. Then multiple EAP6 could connect to the same domain controller and accept its management. Now let's see the servers section.

The servers section

The servers section is shown in the following screenshot:

In the domain mode, a host controller can manage several servers at the same time, and each server has their own name and belongs to a server group; these servers are bound to different sockets to avoid conflicts.

The auto-start option checks whether to start this server during the EAP6 startup. We may choose which server to start during the EAP6 startup by this option.

The port-offset option is used to bind different servers into different ports to avoid conflict. Let's see the default configuration in host.xml:

<servers>
  <server name="server-one" group="main-server-group">
    <socket-bindings port-offset="0"/>
  </server>
  <server name="server-two" group="main-server-group">
    <socket-bindings port-offset="150"/>
  </server>
  <server name="server-three" group="other-server-group">
    <socket-bindings port-offset="250"/>
  </server>
</servers>

The following is the deployment diagram that shows the relationship between the previously discussed servers and server groups:

Here are the server group settings in domain.xml:

<server-groups>
  <server-group name="main-server-group" profile="full">
    <socket-binding-group ref="full-sockets"/>
  </server-group>
  <server-group name="other-server-group" profile="full-ha">
    <socket-binding-group ref="full-ha-sockets"/>
  </server-group>
</server-groups>

We can see that the main-server-group is bound to full-sockets, and the other-server-group is bound to full-ha-sockets. These two sockets are defined as follows:

<socket-binding-group name="full-sockets" default-interface="public">
  <socket-binding name="http" port="8080"/>
</socket-binding-group>
<socket-binding-group name="full-ha-sockets" default-interface="public">
  <socket-binding name="http" port="8080"/>
</socket-binding-group>

The full-sockets binds to the HTTP port 8080, and port-offset is 0. So the web port used by server-one is 8080; for server-two, because its port-offset is 150, its web port is 8080 + 150 = 8230. Similarly, the HTTP port used by server-three is 8080 + 250 = 8330.

Now let's set auto-start for all three servers to true so that they will be started during the EAP6 startup:

<servers>
  <server name="server-one" group="main-server-group" auto-start="true">...</server>
  <server name="server-two" group="main-server-group" auto-start="true">...</server>
  <server name="server-three-master" group="other-server-group" auto-start="true">...</server>
</servers>

Now let's start EAP6 in the domain mode by calling domain.sh. After EAP6 starts, let's try to access 8080, 8230, and 8330 with telnet commands:

$ telnet localhost 8080
Trying localhost...
Connected to localhost.

$ telnet localhost 8230
Trying localhost...
Connected to localhost.

$ telnet localhost 8330
Trying localhost...
Connected to localhost.

We can see all the servers are listening for connections now.