Network Deployment (Distributed operating systems), v8.0 > Applications > Messaging resources > Default messaging > How JMS applications connect to a messaging engine on a bus


How a message-driven bean connects in a cluster

When an enterprise bean (EJB) application is deployed to an application server cluster, the application can run on any of the servers in the cluster to provide high availability and scalability of the application. When the EJB application is a message-driven bean (MDB), it can run on any of the servers in the cluster (for high availability) and can be invoked concurrently in multiple application servers in the cluster (for scalability). This behavior depends on the location of the MDB with respect to any service integration bus members, and on the configuration of the MDB itself.

For ease of management, connect the MDB directly to messaging engines in the bus member that owns the bus queue or subscription that the MDB is servicing, rather than connecting through intermediate messaging engines. For optimum messaging performance, deploy the MDB to the same application server or cluster as the bus member.

By default, when an MDB application is deployed to an application server cluster that is also a service integration bus cluster bus member, the MDB application connects to one or more messaging engines on servers within the cluster. The default connection behavior, and the extra connection control that you can apply to any JMS application including message-driven beans, are described in How JMS applications connect to a messaging engine on a bus. However, if you use the configuration options described in topic, the message-driven bean is only driven on those servers in the cluster that host a started messaging engine.

For MDB applications connecting to a cluster bus member, you can also enable either of the following additional configurations:

These configurations are described in more detail in the following sections:

The diagrams in these sections follow this key:

Figure 1.

Topic diagram key


MDB connection behavior: Within a single cluster bus member

The message-driven bean is driven only on those servers in the cluster bus member that host a started messaging engine

This is the default option. If the message-driven bean is deployed to a cluster bus member then only the MDB endpoints in servers that have a messaging engine started locally are eligible to be driven by available messages.

In figure 2, a cluster bus member contains three servers. server1 and server2 each contain an active and failover messaging engine. The MDB endpoints running in each of these two servers connect to their respective local messaging engines. server3 does not host a started messaging engine, but it is hosting two failover messaging engines. It does not have an active MDB endpoint and is not eligible to consume messages.

Figure 2. MDB is driven by servers in the cluster bus member that hosts a started messaging engine (setup 1)

This configuration also provides high availability of the MDB application, and the messages on the bus destination, if the messaging engines can fail over between servers in the cluster.

In figure 3, the cluster bus member is shown as in the previous figure. The messaging engine in server1 has failed over to server2. Consequently, server2 now contains two active messaging engines and the MDB endpoint running in server2 now connects to both of the local messaging engines. The third server is not hosting a started messaging engine, does not have an active MDB endpoint and is not eligible to consume messages.

Figure 3. MDB is driven by servers in the cluster bus member that hosts a started messaging engine (setup 2)

This configuration is enabled unless you select the Always activate MDBs in all servers option on the activation specification.

All servers in a cluster bus member can receive messages from a message-driven bean

We can set the MDB endpoints in all the cluster servers as eligible to be driven by messages, regardless of whether there is a local started messaging engine. Any MDB endpoint in a server that does not have a started messaging engine connects directly to one of the messaging engines in one of the other servers in the cluster. This approach ensures that all the available resources of the cluster can be used to process the messages that are sent to the destinations.

In figure 4, a cluster bus member contains three servers. Two servers contain active messaging engines. The MDB endpoints in each of these two servers connect to their respective local messaging engines. The third server, that is not hosting a started messaging engine, is workload balanced across the available messaging engines in the cluster. The MDB endpoint in the third server is connected to a messaging engine running in one of the other two servers.

Figure 4. Servers in a cluster bus member receive messages from a message-driven bean

To choose this configuration you select the Always activate MDBs in all servers option on the activation specification.

This configuration achieves the same effect, in terms of which MDB endpoints are driven, as the following configuration (also described in this topic): All servers in a cluster can receive messages from messaging engines in a cluster bus member.


MDB connection behavior: Between a cluster and a separate bus member

All servers in a cluster can receive messages from messaging engines in a cluster bus member

If you deploy the MDB application to a cluster that is not a bus member, the MDB attempts to connect to the bus from every application server in the cluster, following the connection rules described in How JMS applications connect to a messaging engine on a bus. This usually results in all of the MDB endpoints in the cluster being driven concurrently by messages from an active messaging engine in the bus member. This approach ensures that all the available resources of the cluster can be used to process messages sent to destinations in the cluster bus member.

In figure 5, a cluster contains three servers, each with a MDB endpoint. A cluster bus member contains two servers, and one hosts an active messaging engine. Each of the cluster's three MDB endpoints connect to the active messaging engine in the cluster bus member.

Under this configuration connections might not be made to all messaging engines, so there could be a messaging engine that has no connection, and this could result in marooned messages. This situation is less likely to occur if the activation specification used by the MDB is set to server scope.

Figure 5. All servers in cluster receive messages from messaging engines in a cluster bus member

This configuration achieves the same effect, in terms of which MDB endpoints are driven, as the following configuration (also described in this topic): All servers in a cluster bus member can receive messages from a message-driven bean.

Just one server in a cluster can receive messages from a messaging engine in a cluster bus member

To achieve sequential processing of the messages on the destination by a single server at a time, configure the system so that only a single MDB endpoint is driven by messages at any one time. In this pattern the other MDB endpoints and messaging engine are effectively in standby ready to take over processing of messages if server1 stops.

In figure 6, a cluster contains three servers, each with a MDB endpoint. A cluster bus member also contains two servers, one of which has an active messaging engine. Only one of the three MDB endpoints in the cluster is connected to the active messaging engine running in the cluster bus member.

Figure 6. One server receiving messages from messaging engine in a cluster bus member

To choose this configuration you configure the activation specification so that the MDB endpoints in all the non-bus cluster servers are eligible to be driven by messages from a messaging engine in the cluster bus member, and set the receive exclusive option on the destination in the cluster bus member. When one of the MDB endpoints connects to the messaging engine, the engine stops all other available MDB endpoints from connecting and continues to process messages through the same MDB endpoint.

To achieve sequential processing of messages by an MDB further configuration might be required. For more information about ensuring sequential processing of the messages on a destination, see Message ordering.


Bus member types and their effect on high availability and workload sharing
How JMS applications connect to a messaging engine on a bus
Workload sharing with queue destinations
Bus member types and their effect on high availability and workload sharing
Add a cluster as a member of a bus
Add a messaging engine to a cluster
Configure an activation specification for the default messaging provider Concept topic

+

Search Tips   |   Advanced Search