First Beta Release of the mod_cluster Project

On behalf of the teams working on the JBoss Web and JBoss AS Clustering projects, I’m very pleased to announce the 1.0.0.Beta1 release of the mod_cluster project.

For full details on the project, please see the mod_cluster project page on jboss.org. Downloads are available at the project download page.

Like mod_jk and mod_proxy, mod_cluster is an httpd-based load balancer that can proxy requests to a cluster of Tomcat-based webservers (either standalone Tomcat, standalone JBoss Web or JBoss AS’s embedded JBoss Web). Where mod_cluster differs from mod_jk and mod_proxy is that it provides a back channel from the webservers back to the httpd servers. The webservers use this back channel to provide information to the httpd-side about their current state. The use of this back channel provides a number of advantages:

• Dynamic configuration of httpd workers. No more tedious listing of static cluster topologies in workers.properties and uriworkermap.properties. No more having to remember to update workers.properties before adding a new node to a cluster. With mod_cluster, configuration is done on the application server side.  Start a new app server and it registers with the httpd-side, informing it of its configuration. Deploy a war and the app server notifies the httpd-side that URLs for the war’s hostname and context path can be routed to that server. Repetitious configuration is nearly eliminated, since the app server already knows most values, e.g. the address and port of the AJP connector.
• Server-side load balance factor calculation.  A load balancer like mod_jk and mod_proxy_balancer can only base its load balancing decisions on information available on the load balancer side, e.g. how many requests it has passed to each node and how many sessions were associated with those requests. If the cluster is using more than one load balancer, each has no idea about the load being proxied by the others. And none have any knowledge of critical server-side information like CPU or heap utilization. With mod_cluster, the app servers periodically examine their running condition and tell the httpd-side the proportional load each should bear. And a configurable, pluggable set of load metrics gives great flexibility to admins in deciding what runtime metrics should drive the load balancing decision.
• Fine grained web-app lifecycle control.  Traditional httpd-based load balancers do not handle web application undeployments particularly well. From the proxy’s perspective a backend server can handle a given URL if the URL is in the static global configuration and the server’s AJP connector is functioning. So, if you undeploy a war from a running server, the load balancer will continue to route requests for that war’s URLs to that server, leading to 404 errors. In mod_cluster, each server forwards any web application context lifecycle events (e.g. web-app deploy/undeploy) to the proxy informing it to start/stop routing requests for a given context to that server. Requests are stopped before the application undeploys. No more 404s.

An added benefit of mod_cluster is that, unlike mod_jk, use of the AJP protocol between httpd and the back-end servers will be optional. The httpd connections to application server nodes can use HTTP, HTTPS, or AJP. (Note that in this first beta release, testing has been focused on AJP.)

I encourage you to give mod_cluster a try and to give us your feedback. As with all open source projects, community feedback is essential. The best place for feedback is the mod_cluster user forum.

Many thanks to Jean-Frederic Clere, Paul Ferraro and Rémy Maucherat for their hard work on this release; the vast majority of the credit goes to them.

Enjoy!