Clustering

Clustering has been available since version 2.0 and enables multiple JMS servers to cooperate in getting messages from producer applications to consumer applications. Clustering makes it easier to write applications that have better scalability and are less sensitive to partial system failures. This chapter provides a high level introduction to clustering in the Novell exteNd Messaging Platform JMS.

A main objective when using messaging middleware is to shield applications and application programmers from complex error situations occurring when system components are unavailable: storing all messaging in an intermediary destination allows sender applications to operate independently of receiver applications. This benefit can naturally only be provided if the messaging middleware is available at all times.

However, all individual software components are subject to downtime because of software failures, hardware failures or maintenance. Components that require very high availability can therefore typically be configured to run as several components executing in parallel. A configuration where several components can cooperate and avoid single points of failure is called a cluster. A cluster provides the following:

Fault tolerance. Client applications will be shielded from partial cluster failures (failure of individual servers). While throughput and latency may be affected, the system will continue to function as long as any part of the cluster is functioning.
Load balance. Although a cluster introduces some overhead to maintain the illusion of a single server, more servers running in parallel can improve throughput and latency as client applications can spread load across the servers.

The ultimate goal of clustering is to provide the above benefits as transparently to the application developer as possible. For some types of middleware, clustering can be completely transparent, i.e. application programmers simply write their programs as if they were using a single server -- any fail-over required during partial failures or load-balancing algorithms deployed is automatically done by the middleware.

Clustering in a messaging system is often different from clustering in other types of middleware. Consider for instance replicating a queue on two servers. The overhead of ensuring that only one consumer connected to one of the servers receives a message sent to the queue is very significant. Rather than having a clustered messaging server with extremely reduced throughput capabilities, a more pragmatic approach to clustering is therefore typically chosen.

Clustering

The JMS server supports clustering by synchronizing the destination and security state across the servers in a cluster. This means that all destinations are available on all servers throughout the cluster. Each JMS server in the cluster can also forward messages to other cluster members. Message forwarding is different for queues and topics:

Topic messages are by default always forwarded since topics are conceptually everywhere. This means that applications can send or receive messages from a topic using any server in the cluster.
Queue messages are forwarded if a queue receiver for a particular destination is connected to a different server in the cluster. This means that queues are not cluster wide, but they can be accessed from any server in the cluster.

The above strategy provides the same semantics for queues and topics as in a single server system. Topic subscribers will receive all messages sent to a topic after the subscription was first made. Queue receivers will receive un-consumed messages from a queue in round-robin fashion. The only difference is that consumers can receive messages from a different server than the message was originally sent to.

Figure 1:Overview of clustering in Novell exteNd Messaging Platform JMS.

Partial cluster failures are not transparent to consumer applications since message acknowledgement must occur on the same server that delivered the message to the consumer. However, once the consumer has dealt with a failed message acknowledgement, it can connect to another server in the cluster and continue message processing from there. Queue receivers are encouraged to always prefer to connect to the server where the queue resides for performance reasons.

Another consequence of clustering can be seen in Figure 2 below. A consumer connected to one broker may see a different message ordering than a consumer connected to another broker since messages are exchanged asynchronously between brokers in a cluster. Applications that have very stringent ordering requirements should rely on message timestamps when using a cluster. Also, messages may been delayed for as long as it takes to re-start a failed broker.

Figure 2:Message ordering can be affected when using clustering.

For producer applications, clustering is completely transparent in most cases. If one server in the cluster fails, the producer will automatically be reconnected to any available server in the cluster and continue sending messages to that server. A special case involves a distributed transaction, which must always run to completion using one server only. Note that transparent fail-over is only enabled when the producer's connection has no consumers in any of its sessions.

Load Balancing

The connection factories contain address information for all JMS servers participating in a cluster. Client applications will automatically run in a cluster aware mode if they are bootstrapped with an administered object that is configured for clustering. The client application can alternatively be explicitly configured for clustering if the bootstrap process must also be fault-tolerant.

The destination factories are typically resolved from JNDI using the following URLs:

     queue://[h:p][,h:p]*/connectionFactory
     queue://[h:p][,h:p]*/xaConnectionFactory
     topic://[h:p][,h:p]*/connectionFactory
     topic://[h:p][,h:p]*/xaConnectionFactory

As an example, a client can resolve the queue connection factory like this:

     queue://jms1:53506,jms2:53506/connectionFactory

Using this URL, the queue connection factory will be resolved and configured with address information for both servers. The first server in the list will be the primary server, while the remaining servers in the list are secondary servers. If different producer applications use different primary hosts, load balancing occurs. Applications that do not use JNDI can instantiate the connection factories and set the secondary servers using the JMQServerInfo data structure.

Administration

The JMS cluster consists of a set of loosely coupled JMS servers that share state and cooperate in processing messages. Any number of servers can be configured to participate in a cluster, but the cluster size should be matched to fit the availability requirements of the application. Cluster members can be added and removed dynamically as long as destination or security information is not modified at the same time.

A main advantage of the JMS cluster is that it is not based on a shared database. Instead, persistent messages and information about destinations can be kept in separate databases for each server in the cluster. Since JMS servers leverage dual home network support in the ORB, this means that the JMS cluster does not have a single point of failure. If a high-availability database is present, all servers in the cluster can be configured to share the database (but not tables).

The JMS cluster configuration is specified using the following properties from the JMQMessageService interface:

msgsvc.cluster.members - A list of URL's for other brokers in a JMS cluster.

msgsvc.cluster.topics - A comma separated list of topics for which messages will be forwarded in a cluster. By default this property is not specified, which means that all topic are cluster wide.

These properties are part of the msgsvc.properties file used by the JMS server program jmqserv.