A Universal Messaging client, whether using the Universal Messaging API or JMS, accesses Universal Messaging realms and their resources through a custom URL called an RNAME. When accessing resources in a cluster, clients use a comma separated array of RNAMEs. This comma separated array can be given to the client dynamically when the client connects to any member of a cluster. If a connection is terminated unexpectedly, the Universal Messaging client automatically uses the next RNAME in its array to carry on.

For example, if we have a cluster consisting of 3 realms, your nirvana nSession can be constructed using the 3 RNAME URLs associated with each of the realms in the cluster.

Once connected to a realm in a cluster, you can then obtain references to nChannel and nQueue objects (or in JMS, create a Session followed by a topic or queue).

Each event/message within Universal Messaging is uniquely identified by an event ID regardless of whether it is stored on a channel, topic or queue. A clustered channel, topic or queue guarantees that every event published to it via any realm within the cluster will be propagated to every other realm in the cluster and will be identified with the same unique event ID. This enables clients to seamlessly move from realm to realm after disconnection and ensure that they begin from the last event consumed based on this unique event ID.

For scenarios where failover is handled at the network level, Universal Messaging sessions can be moved to alternate servers transparently without the use of multiple RNAMEs.

Using an array of RNAME URLs allows client applications to seamlessly fail over to different cluster nodes without the use of any third party failover software.

For example, in a three realm clustered scenario, a client's RNAME string may contain the following RNAME URLs:

When we first connect, the rnames[0] (in this example, nsp://host1:9000) will be used by the session, and the client application will connect to this realm. However, should we disconnect from this realm, for example if host1 crashes, the client API will automatically reconnect the client application to the cluster member found at rnames[1], which is nsp://host2:9000.

The Universal Messaging client API for Java allows you to configure a session so that it is always connected to the master node in a cluster (the client will follow the master). This behavior can be configured through the method setFollowTheMaster of the nSessionAttributes class (Universal Messaging client API), or in the JMS ConnectionFactory. The default configuration is that the client will not follow the master.

You can also configure the client to follow the master by setting the system property FollowTheMaster on the client side when you start your client application. To do this, use "-DFollowTheMaster=true" on the command line. Alternatively, you can invoke java.lang.System.setProperty("FollowTheMaster", "true") in your client application code.