Show TOC

JMS Clustering and Failover Locate this document in the navigation structure

JMS Virtual Providers

A JMS Virtual Provider:

  • defines a different namespace, which gives your application the freedom to use whatever names you want for the JMS resources without a naming conflict. For example, you can have two queues with one and the same name as long as they reside on different Virtual Providers.

  • A JMS Virtual Provider is the minimum set of JMS resources that can be atomically hosted (that is, all of the resources or none of them) by a server process. In other words, the JMS resources are logically grouped together into Virtual Providers. Every server process may host zero, one, or more JMS Virtual Providers.

JMS Clustering

There are two clustering options for a JMS Virtual Provider:

  • Global JMS Virtual Provider

    A Global JMS Virtual Provider is instantiated (hosted) on exactly one server process in the cluster. All requests concerning JMS resources of this Virtual Provider are redirected to and processed on the hosting server process. Message consumers registered to destinations belonging to a Global JMS Virtual Provider receive the messages that have been produced on any server process. In case the server process hosting the Global JMS Virtual Provider crashes, there is automatic failover and this Virtual Provider is “transferred” to another server process.

    Note that due to the clustering of the Global JMS Virtual Providers, the instances of the JMS Provider service that run on different server process are not identical, that is, JMS is heterogeneous in the cluster. Some server processes may host a subset of JMS resources (connection factories and destinations), while others may not host any JMS resources (JMS backup server processes).

    If you want a server process to host no more than one Virtual Provider, you have to set the property hostMultipleVPs to false using the Config Tool. You have to start the Config Tool by double-clicking the configtool script file in <SAP_install_dir>/<system_name>/<instance_name>/j2ee/configtool directory and expand the nodes   cluster-data   template-CE_JAVA_EE_development_full   services   jms_provider  .

    Here is an example topology of a cluster with six server processes, two of them are hosting a Global JMS Virtual Provider (a “blue” one hosted by Server Process 4 and a “red” one hosted by Server Process 1). For the “blue” JMS Virtual Provider, there are two message producers (on Server Process 0 and Server Process 3) and one message consumer (on Sever Process 2) and for the “red” JMS Virtual Provider there is one message producer (on Server Process 3) and one message consumer (on Server Process 5).

    This graphic is explained in the accompanying text.

    Clustering of Global JMS Virtual Providers

  • Local JMS Virtual Provider

    A Local JMS Virtual Provider is instantiated on every server process in the cluster. Message consumers registered to destinations belonging to a Local JMS Virtual Provider receive only the messages that have been produced locally, that is, on the same server process. In case the server process hosting the Local JMS Virtual Provider crashes, there is no failover because it is not necessary — all message producers and consumers registered to destinations belonging to the instance of the Local JMS Virtual Provider on the crashed server process become unavailable as well.

    Here is another example topology of a cluster with six server processes, with two Local JMS Virtual Providers (a “blue” one and a “red” one). Each of the two Virtual Providers is instantiated on (hosted by) each server process in the cluster. The messages produced on a server process are delivered only to consumers residing on the same server process.

    This graphic is explained in the accompanying text.

    Clustering of Local JMS Virtual Providers

By default, JMS Virtual Providers are Global. The clustering behavior is a configuration property of JMS Virtual Providers called runningMode.

Recommendation Recommendation

We recommend to use Local Virtual Providers as a JMS clustering option. They provide full scalability and optimum performance to JMS applications, together with simplicity, as there is no need for implementing failover logic (there is no single point of failure in the cluster). Global JMS Virtual Providers should only be used by an application whose design requires JMS semantics that cannot be implemented by Local Virtual Providers. Such design should be carefully considered as it renders the application heterogeneous in a cluster environment, which contradicts to the concept of clustering. The JMS Provider is intended for reliable communication between Java EE applications rather than for implementing cluster communication on top of it.

End of the recommendation.

More information: Creating and Configuring JMS Virtual Providers

Message-Driven Bean Clustering

There are two options regarding the distribution of the active MDB instances in a cluster — either an MDB instance is activated on every server process (the default option) or on exactly one (randomly selected) server process. You can configure this using the MDB property single-server-node in the ejb-j2ee-engine.xml. If the property is set to false, the MDB is activated on just one server process in the cluster.

Both Queue and Topic MDBs are activated on all server processes by default. In case this is a Queue MDB and an instance of it is activated on each server process, the messages in the respective queue will be distributed to the active MDB instances on the different server processes in a round-robin fashion. This is a common pattern for achieving load balancing by MDB applications.

In case of Topic MDB activated on all server processes, a copy of each JMS message is delivered to an MDB instance on each server process. If your application needs single processing of the Topic messages, you need to configure it to be activated on a single server process.

Alternatively, you can register the MDB to a destination belonging to a Local JMS Virtual Provider. In this case, even though the MDB is activated on every server process, each message (produced anywhere in the cluster) will be processed by exactly one MDB instance – one residing on the same server process as the message producer. This second approach is preferable to the first one because you will gain scalability (processing will take place on all server processes where there is a message producer) and improved reliability (you have no single point of failure as with Global JMS Virtual Providers).

More information: Setting the MDB Properties in the ejb-j2ee-engine.xml

JMS Failover

If a server process hosting one or more Global JMS Virtual Providers crashes, all other server processes detect the crash of this server process and compete to obtain its Virtual Providers and distribute them among themselves. Note that the failover of Global JMS Virtual Providers is automatic and it does not require any manual configuration. However, failover is not transparent to applications. While failover is taking place, the JMS resources of the Virtual Provider(s), which are being transferred to another server process, are temporarily unavailable. Applications must handle this case with appropriate reconnection logic.

Local JMS Virtual Providers do not have (and do not need) failover. Messages produced by local producers (that is, residing on the crashing server process) are visible only to local consumers (residing on the same server process). That is why the crash of any Local JMS Virtual Providers does not affect in any way applications running on the other server processes of the cluster.

Message-Driven Bean Failover

MDBs listening to destinations belonging to Global JMS Virtual Providers have automatic failover and, upon detecting a failover condition, will try to reconnect. Each MDB will perform a number of reconnection attempts, with some sleep between two consecutive attempts. The two properties that determine the MDB reconnection – maximum number of reconnection attempts (reconnect-attempts) and the sleep time between two attempts (sleep-between-attempts) – are configurable in ejb-j2ee-engine.xml. Once the reconnection attempts of an MDB have been exhausted, it will never try to reconnect again and it will not receive any messages since. Note that the optimum values of the two reconnection-related configuration properties depend on the hardware setup, the cluster size, the cluster load and all other factors that may influence the time necessary for a successful failover of the Global JMS Virtual Provider.