Mod_cluster uses a communication channel to forward requests from balancer to worker nodes and another channel to receive load and application lifecycle events from worker nodes.

Balancer

Mod_cluster load balancing logic is implemented in a set of Apache HTTP Server modules, in a suite of modules for Nginx and last but not least, as a part of Undertow web server; usable both as Undertow standalone and as a Wildfly server. All these projects are striving to maintain protocol compatibility.

Worker

Mod_cluster, unlike other proxies such as mod_proxy or mod_jk, uses worker-side libraries that tap into servlet containers life cycles. These libraries are implemented for Tomcat 6+, JBoss AS 5+ and Wildfly. One could have a Wildfly balancer with Wildfly workers, Apache HTTP Server balancer with Wildfly or Tomcat workers etc.

Communication channel

Mod_cluster workers are either configured with Mod_cluster balancer address or they listen to UDP multicast advertising of Mod_cluster balancer where they learn the address and port of Mod_cluster balancer.

Worker nodes proceed on registering themselves with the balancer by sending custom HTTP methods messages, telling the balancer where to contact them, i.e. worker's addresses and ports, and most importantly, which web application contexts they have deployed. Workers periodically send information about their current load or lifecycle events, e.g. re-deployment, shutting down etc.

Balancer sends client's requests to worker nodes and processes replies. It only addresses a worker node if the worker node responds to a special "ping" on application layer. It means that it is not enough for the balancer that the TCP connection to worker is open, it actively ascertains that the worker is really processing requests.

From balancer to workers

Mod_cluster balancer offers these protocols for sending requests to worker nodes: AJP, HTTP, HTTPS, WS/WSS (Apache HTTP Server and Undertow implementations), HTTP/2 (Undertow implementation).

From workers to balancer

Mod_cluster management messages use either HTTP, HTTPS or HTTP/2.

Why mod_cluster

Mod_cluster provides quite a few distinct advantages over mod_jk or mod_proxy:

• Improved load balancing between worker nodes since the load metric is calculated directly by the worker node instead of the load balancer
• Mod_cluster is aware of the lifecyle of applications in the application server so it knows when an application gets deployed or undeployed
• It supports all mainstream protocols - AJP, HTTP, HTTPS, WS/WSS, HTTP/2, unlike mod_jk which only supports AJP
• It uses advertisement of balancers location so workers could find it without any static configuration. It makes it very easy especially in a cloud environment to automatically add or remove nodes based on the load factor

More information can be found on the mod_cluster community page http://modcluster.io.