Chapter 3. Clustering overview

3.1. JBoss Messaging Clustering Overview

Here's a brief overview of how clustering works in JBoss Messaging 1.2.

As mentioned in the previous chapter, please note that not all this functionality is available in this release.

Clustered destinations (queues and topics) can be deployed at all or none of the nodes of the cluster.

A JMS client uses HA JNDI to lookup the connection factory. A client side load balancing policy will automatically chose a node to connect to (This is similar to how EJB clustering chooses a node).

The JMS client has now made a connection to a node where it can create sessions, message producers and message consumers and browsers and send or consume messages, using the standard JMS api.

When a distributed queue is deployed across the cluster, individual partial queues are deployed on each node.

When a message is sent from a message producer attached to a particular node to a distributed quueue, a routing policy determines which partial queue will receive the message.

By default the router will always pass the message to a local queue, if there is one, this is so we avoid unnecessary network traffic.

If there is no local queue then a partial queue on a different node will be chosen by the router, by default this will be round robin between remote partial queues.

When a message is sent to a distributed topic while attached to a node, there may be multiple subscriptions on different nodes that need to receive the message. Depending on the number and location of subscriptions, the message may be multicast or unicast across the cluster so the other nodes can pick it up.

All group communication, unicast, multicast and group management is handled by JGroups.

In the case of shared durable subscriptions, if a durable subscription with the same name exists on more than node, then only one of the instances needs to receive the message.

Which one is determined by the same routing policy used to route messages to partial queues.

All of this is accomplished without losing the reliability guarantees required by JMS.

Subscriptions (both durable and non durable) can be created on all nodes and will receive messages sent via any node.

What happens if the consumers on one queue/subscription are faster/slower than consumers on another?

Normally this would result in messages building up on that queue and fast consumers being starved of work on another, thus wasting CPU cycles on the node that could be put to good use.

The most degenerate example is of a queue containing many messages then the consumers being closed on that queue. The messages might potentially remain stranded on the queue until another consumer attaches.

A routing policy is no use here, since the messages have already been routed to the queuee and the consumers closed / slowed down after they were routed there.

JBoss Messaging deals with this problem by intelligently pulling messages from other less busy nodes, if it detects idle consumers on the fast node and slow consumers on another node.

Another feature (not available in CR1) that will enable very fast, very scalable reliable messaging without using databases is in memory replication of reliable messages.

Normally, persistent messages are persisted in a shared database which is shared by all nodes in the cluster. JBoss Messaging 1.2.GA will contain an option where you can choose to not persist persistent messages in a database, but instead to replicate them between nodes of the cluster.

The idea here is the network IO on a fast network should be much faster than persisting to disk.

This solution should also be more scalable since different nodes replicate their messages onto different other nodes - there is no "master node".

If the messages are replicated onto suffficient nodes and the hardware is set-up with UPS, then we believe a comparable reliability guarantee to persisting messages to disk can be achieved. Of course, this won't be suitable for all situations, but you use the best tool for the job.