Configuring JBoss 7 with Apache

There are a number of articles out there about deploying applications to JBoss and about how to monitor JBoss, and in them the web application is usually accessed by pointing a browser to the web container running on port 8080. In enterprise production environments however, the application server does not exist in a vacuum – JBoss is usually fronted with the web server (most often Apache). This kind of setup brings about several benefits:




  • Improved security by limiting access to the app server. In an Internet application the web server is accessed directly by the clients. Separating the web server from the app server allows us to place the former in a Demilitarized Zone (DMZ), while the app server can live on a more protected corporate network. If the web server is compromised, there is an additional barrier for the hackers to overcome before they can get access to your precious application and database servers.
  • Some third-party plugins allow the web server to perform authentication against LDAP or RADIUS servers – unauthenticated/unauthorized requests do not even reach your application server.
  • Improved performance by caching static content. Apache can cache your static content (images, javascript and .css), while allowing the app server to concentrate on what it does best – business logic processing
  • Improved SSL performance. SSL performs on-the-fly encryption/decryption which can be computationally expensive. While JBoss can certainly handle it, it makes more sense to take the load off its shoulders and allow Apache to do the SSL heavy lifting (Apache can even use hardware SSL acceleration)
  • Last but not least, given the right setup, Apache can balance the load between your application servers very effectively (we will see how in a minute).

For simplicity, let’s assume the following:

  • we are running JBoss 7.1 in standalone mode
  • the operating system is CentOS 6.x
  • $JBOSS_HOME refers to the JBoss 7 installation directory (you don’t have to set this environment variable)
  • We will use the Monitis JMX agent web application to illustrate the process – the web application context is mon_jmx_agent

Configuring AJP

AJP stands for “Apache JServ Protocol” – this is the standard method of interfacing Apache with Tomcat (and later, JBoss) since the earliest versions of Tomcat. It is a packet-based protocol, which in it’s latest re-incarnation of 1.3 is very fast, while adding very little overhead. Tomcat (and by extension JBoss) speaks AJP out of the box. On the Apache side, the mod_proxy_ajp provides the necessary functionality. So let’s see how to put the whole thing together.

Step 1.Enable the AJP connector In JBoss 7 the AJP connector is not enabled by default, so let’s enable it. Open $JBOSS_HOME/standalone/configuration/standalone.xml, find the subsystem tag and add the AJP connector:

        <subsystem xmlns="urn:jboss:domain:web:1.1" native="false" default-virtual-server="default-host">
            <connector name="ajp" protocol="AJP/1.3" scheme="http" socket-binding="ajp"/>

Next, make sure that the ajp socket binding definition exists:

    <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
        <socket-binding name="ajp" port="8009"/>

Step 2. Configure mod_proxy_ajp Go to /etc/httpd/conf.d and create a file proxy_ajp.conf as follows

<IfModule !proxy_ajp_module>
  LoadModule proxy_ajp_module modules/
ProxyPass /mon_jmx_agent ajp://localhost:8009/mon_jmx_agent

Step 3. Restart JBoss and Apache (in that order)
Now, open a web browser and navigate to http://localhost/mon_jmx_agent. You should see the JMX agent’s login screen.

Configuring mod_cluster

If you are running a cluster of multiple JBoss instances, you will need a load balancer to distribute the load between them. While both mod_proxy_ajp and mod_proxy_http do provide basic load-balancing functionality, it is somewhat limited. The most flexible way to implement load-balancing with apache nowadays is mod_cluster. Besides simply forwarding the requests to the cluster nodes, mod_cluster maintains a separate communication channel to the cluster nodes. This allows for more fine-grained load balancing based on a wider range of load-related parameters calculated by the cluster nodes. It also allows the cluster nodes to communicate lifecycle events to the mod_cluster load balancer, so that it can re-route the traffic accordingly. For instance, if you undeploy a WAR file on one of the cluster nodes, the load balancer will be aware of that and will route the requests to other nodes. Another important point is that mod_cluster supports dynamic discovery – the balancer does not need to be explicitly configured with the IP address/port numbers of the individual nodes.

Step 1. Configure yum for the EPEL repository (if not already enabled) Since mod_cluster is not yet part of the Apache distribution, we have to download separately from the EPEL repository, so let’s make sure yum is configured for this repository:

To check if EPEL is already configured in YUM, do

$rpm -qa epel-release

If the search results comes back blank, download the EPEL RPM from here (choose the appropriate version for the OS version you are running) and install it in order to configure yum for the EPEL repo:

$rpm -i epel-release-6-5.noarch.rpm

Step 2. Install mod_cluster and dependent modules

$yum install mod_cluster

Step 3: Configure mod_cluster

Step 3a. Open /etc/https/http.conf and make sure the following modules are enabled:

LoadModule proxy_module /modules/
LoadModule proxy_ajp_module /modules/
LoadModule slotmem_module /modules/
LoadModule manager_module /modules/
LoadModule proxy_cluster_module /modules/
LoadModule advertise_module /modules/

Step 3b. Create a file mod_cluster.conf in /etc/httpd/conf.d as follows:

<IfModule manager_module>
    Listen   # change IP address to suit your environment
    ManagerBalancerName mycluster
    <VirtualHost> # change IP address to suit your environment
        KeepAliveTimeout 300
        MaxKeepAliveRequests 0
        ServerAdvertise On
        AdvertiseSecurityKey secret # change key to match jboss config below

        <Location />
            Order deny,allow
      Deny from all
            Allow from 192.168.1. #change IP address filter to allow access from your local network

Step 3c. Modify /etc/httpd/httpd.conf like so:

<VirtualHost *:80>
    ProxyPass / balancer://mycluster stickysession=JSESSIONID|jsessionid nofailover=On
    ProxyPassReverse / balancer://mycluster
    ProxyPreserveHost On

    <Location />
        Order deny,allow
        Allow from All

    <Location /mod_cluster_manager>
        SetHandler mod_cluster-manager
        Order deny,allow
        Deny from all
        Allow from 192.168.1. # change this to match your network setup

Step 3d: Modify the JBoss config file $JBOSS_HOME/standalone/configuration/standalone-ha.xml

    <extension module=""/>

<subsystem xmlns="urn:jboss:domain:modcluster:1.0">
    <mod-cluster-config advertise-socket="modcluster" advertise-security-key="secret"/>

<socket-binding-group name="standard-sockets" default-interface="public"
    <socket-binding name="modcluster" port="0" multicast-address="" multicast-port="23364"/>

Step 4. Start httpd

Step 5. Start JBoss with the standalone-ha.xml profile

That’s it. Open up a web browser and navigate to and you should see the internal status page of the cluster manager:

The Contexts heading lists all application contexts (i.e. web applications) which are configures for this node. You should be able to open the Monitis JMX agent web application in a separate browser window: (change the IP address as necessary).

Note: If the status page is blank, then the cluster nodes are not registering properly with the balancer. Make sure IP multicast is enabled between the web server and the app server machine (mod_cluster’s discovery functionality uses IP Multicast to advertise the balancer’s address and port to the cluster nodes). The usual culprits are SELinux and iptables, so you may have to create the appropriate rules. Alternatively, you can point JBoss 7 to the balancer explicitly instead of relying on autodiscovery. Replace the following line in the JBoss configuration file standalone-ha.conf:

<mod-cluster-config advertise-socket="modcluster" advertise-security-key="secret"/>


with one like this:

<mod-cluster-config proxy-list=""/>

For more information: