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, including:

• Dynamic configuration of httpd workers.
• Server-side load balance factor calculation.
• Fine grained web-app lifecycle control.

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.) More on this in Brian's blog here. Here are the project page and forum, or you can just download the binaries here.

This sounds interesting, I'll have to checkout the site. I'm curious on a few things and to stir up more interest you may want to include some info. Dynamic configuration of httpd workers. - This is kind of ambiguous, can you provide more details? AFAIK you can do this with the status worker or is this a different type of dynamic configuration? Server-side load balance factor calculation. - more diverse than worker.method? *busyness method Fine grained web-app lifecycle control. - not sure what this means. So I'll definitely have to checkout the project page :) Has this been tested with Glassfish at all?

Has this been tested with Glassfish at all?

I'm not good at these cluster things, but why do you need it with Glassfish? As far as I remember, when I installed Glassfish, we can choose to install it in a cluster mode.

Dynamic configuration of httpd workers. - This is kind of ambiguous, can you provide more details? AFAIK you can do this with the status worker or is this a different type of dynamic configuration?

True you can edit a workers.properties and the change will be picked up by the status worker. But why should you have to do this to bring up a new node? The worker knows the name and address on which it's listening for requests; it can register itself with the load balancer.

Server-side load balance factor calculation. - more diverse than worker.method? *busyness method

Yes. The mod_jk busyness method uses the number of requests the servers are currently handling. Not all requests are equal; a bunch of requests for a tiny graphic put less load on a server than a single request that reads a bunch of data from a db and performs complex manipulations on the data. Basically, load balancers that use techniques like busyness are using very incomplete information to estimate server load. With mod_cluster, the information can be much more complete -- basically any metric a server can gather about its own runtime state can be used. The user can configure what metrics are appropriate for their given application, as discussed at the Server Load Metrics page on the mod_cluster site. Mod_cluster ships with metrics for CPU usage, JVM heap usage, system (not just vm) memory usage and JCA connection pool usage. There are also analogues for the mod_jk Request, Session and Traffic metrics. The whole system is pluggable, so users can add other metrics if needed.

Fine grained web-app lifecycle control. - not sure what this means.

With mod_jk, if you list a URL pattern in uriworkermap.properties and a node in workers.properties, if that node's AJP connector is working mod_jk will route requests for a URL to that worker, whether or not the webapp is actually deployed. Result is a 404. With mod_cluster, a worker notifies the httpd side when a webapp is deployed, and also notifies when the webapp is undeployed. Requests for that webapp are only routed to that worker when it has the webapp deployed. No more 404s.

Has this been tested with Glassfish at all?

No. This would be a good area for community involvement.

Requirements * httpd-2.2.8+ * JBoss AS 5.0.0.CR2+ or JBossWeb 2.1.1+

Are you planning a backport for the jboss customers that are using jboss 4.3.0?

Are you planning a backport for the jboss customers that are using jboss 4.3.0?

That isn't something we've discussed. That's not to say that we won't consider it, just that it hasn't been on our agenda. When it comes to integration into JBoss AS, our initial focus is going to be on the AS 5 series.

We already have mod_proxy_balancer. what is the difference now?

3 major differences: 1. In mod_proxy_balancer, the load of each app server is measured by the httpd module using one of the few metrics it has available: request count, traffic, or pending requests. In mod_cluster, app servers determine their own load, based on one or more load metrics, periodically updating the load balance factors in httpd. This allows mod_cluster to balance requests more intelligently based on more robust metrics, like CPU load, memory usage, active sessions, etc. 2. mod_proxy_balancer requires each BalancerMember to be explicitly defined in its configuration. If you want to add a new app server to your cluster, your config file needs to be edited and httpd restarted. In mod_cluster, the app servers notify httpd of their existence, eliminating the need for this static configuration. Consequently, app servers can be added/subtracted to/from the cluster without having to restart httpd. 3. mod_proxy_balancer cannot tell the difference between a request for an undeployed web application and a request for a non-existent resource. mod_cluster uses more fine-grained control over load balancing to include the lifecycle of individual web apps. In mod_cluster, undeploying a web-app on a given server will stop requests for the web app from can being directed to that server, though it will continue to receive requests for other web apps.