Brian Stansberry's Blog

December 2, 2009

Clustering Features in JBoss Application Server 6.0.0.M1

Filed under: JBoss — Brian Stansberry @ 11:00 am

I’m very happy to report that the first milestone release of the community driven JBoss Application Server 6 series was released today. It’s available from and It includes support for some of the key technologies that are part of the EE6 specification, including:

Additional capabilities will be added in future milestones; be sure to keep an eye out for them!

In this post I’ll touch on a couple of the clustering-related features in AS 6.0.0.M1.

Integrated Support for the mod_cluster Load Balancer

The biggest new clustering-related feature in M1 is Paul Ferraro’s addition of out of the box support for mod_cluster. Thanks to the Jean-Frederic Clere’s leadership, a lot of hard work from Paul Ferraro and the mod_cluster team as well as excellent community feedback, mod_cluster has progressed rapidly since I first blogged about it. It’s always been possible to integrate mod_cluster into JBoss AS, but now Paul has done most of the leg-work for you.

The mod_cluster integration is included in the AS’ default, standard and all profiles. Currently it’s not included in the web profile.

To enable mod_cluster support in the AS, you need to do a couple things:

  1. Ensure that JBoss Web uses mod_cluster. This is simply a matter of uncommenting the following in the $JBOSS_HOME/server/[profile name]/deploy/jbossweb.sar/META-INF/jboss-beans.xml file.
    <!-- Uncomment to enable mod_cluster integration -->

    In a later AS 6 milestone, our goal is to remove the need for this step.

  2. Configure a unique name (known as a “jvmRoute”) for each back end server in your cluster. This is configured by adding an attribute to the Engine element in server.xml.
    <Engine name="jboss.web" defaultHost="localhost" jvmRoute="node01">

    Instead of hard-coding the jvmRoute in each server’s server.xml, I recommend instead using system property substitution:

    <Engine name="jboss.web" defaultHost="localhost" jvmRoute="${jboss.jvmRoute}">

    This allows you to control the value from the command line:

    $ ./ -Djboss.jvmRoute=node01

    Configuring a jvmRoute is not absolutely required; if one isn’t provided mod_cluster will generate one from the address and port of the JBoss Web Connector used for receiving requests, plus the name of the JBoss Web Engine. Still, configuring a jvmRoute is recommended, since the jvmRoute is appended to all session ids. The generated jvmRoute is lengthy and includes information you may not want to expose to the internet via session ids.

There are a number of cool improvements in the 1.1.0.Beta1 release of mod_cluster that ships with AS 6.0.0.M1. Check out Paul Ferraro’s blog entry to learn more.

HA Web Sessions via Database Persistence

Occasionally we receive input from the JBoss AS user community that they’d like to see an option to use database persistence as a mechanism to make web sessions highly available. The basic use case we hear for this is for environments where sessions need to be available to AS instances located across a WAN. The main (and still recommended) mechanism for making web sessions HA is to use our standard replication-based approach, which uses the JBoss Cache distributed caching library to replicate sessions to other nodes in the cluster. JBoss Cache/JGroups clusters can span a WAN but sometimes users find it impractical to configure their cluster(s) in that way. However, if their IT infrastructure already supports making RDBMS data accessible across the WAN, persisting sessions to the DB makes them available across the WAN.

JBoss 6.0.0.M1 is the first community release that includes support for this feature. I’ve created a wiki page with full details on how to configure the AS and your application for database persistence.

Improvements to Clustered Caching of Frequently Inserted Entity Types

Just a follow up to something I blogged about a couple months ago: a simple change to the Hibernate Second Level Cache integration with JBoss Cache makes it more performant to cache of entity types with frequent INSERTs but infrequent UPDATEs. AS 6.0.0.M1 includes this improvement.

Ok, enough blogging! Gotta get busy on milestone 2!



  1. […] and interview, Dimitris[15] and Jason[17] have nice summaries of AS 6.0.0.M1, and Brian discusses[16] some new clustering features as […]

    Pingback by No Pain, No Pain | Embedded APIs for JBossAS « Exit Condition — December 2, 2009 @ 5:59 pm | Reply

  2. Paul Ferraro has blogged about mod_cluster 1.1.0.Beta1 — check it out at

    (I edited the blog post to include the link as well.)

    Comment by Brian Stansberry — December 3, 2009 @ 4:18 pm | Reply

  3. […] clustering features are now based on mod_cluster. Don’t miss Brian’s blog, if you plan to enable […]

    Pingback by Java EE 6 receives official approval and JBoss AS 6.0.0 M1 is out! « Bruno Georges's Blog — December 8, 2009 @ 9:54 pm | Reply

  4. How are you gonna get rid of step 1? Simply load it if available and that’s it? What does this listener do in particular? With mod_jk there didn’t use to be any AFAIK.

    Comment by Galder Zamarreno — January 14, 2010 @ 10:17 am | Reply

    • Well, one way would be to just have it uncommented by default. Not the slickest but meets the *stated* objective. 🙂 Downside of that is people who don’t use mod_cluster and want the lightest possible AS need to remove the dependency. To reduce the need for that Paul’s done work to minimize any overhead of the java-side ModClusterService if it’s not actually interacting with any httpd proxy servers; e.g. don’t periodically calculate load balancing factors if there’s no proxy server using that info.

      More sophisticated would be changes in the AS’s ProfileService such that a “depends-if-exists” semantic is available. I hope that will get in AS 6.

      Another *theoretical* option, but not AFAIK being pursued is to use the MC’s incallback mechanism such that if ModClusterService happened to start after TomcatService, MCS would be injected into TS at that time. TS and MCS would then have to coordinate to allow MCS to examine the current state of TS (e.g. what connectors, engines, hosts, context are deployed) so it could relay that info to the httpd proxies. Instead of getting the initial startup state by listening for events from TS, MCS somehow asks for it.

      Comment by Brian Stansberry — January 14, 2010 @ 10:41 am | Reply

  5. DB persistence for sessions can be a useful feature for geographic redundancy.

    Comment by Aayush — October 31, 2010 @ 5:45 am | Reply

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

Create a free website or blog at

%d bloggers like this: