One bus, one bus member (a cluster)
Overview
When the bus member is a cluster, by default, only one appserver has an active messaging engine. If the appserver fails, the messaging engine on another appserver in the cluster is activated, provideing failover, but no workload management. The appserver with the active messaging engine has local access to the bus, but the rest of the appservers in the cluster consume asynchronous messages with remote connections. An MDB deployed to the cluster can only consume from a local messaging engine. Because everything is tunnelled through one messaging engine, performance might still be an issue.
Single bus with a cluster member: High availability
Configuring so that only preferred appservers are used might circumvent the high availability advantages of the cluster if there are no more preferred appservers available.
With some additional configuration, we can create a topology where each appserver in the cluster will be configured to have an active messaging engine, thus providing workload management as well as failover. Note that because messaging engines can run on any appserver, if one appserver goes down, both messaging engines will run on the remaining appserver.
Single bus with a cluster member: Workload management
When a queue destination is assigned to the cluster, the queue is partitioned with each messaging engine in the cluster owning a partition of the queue. A message sent to the queue will be assigned to one partition. The messaging engine that owns the partition is responsible for managing the message. This means that requests sent to a destination can be served on any of the messaging engines running on any of the appservers in the cluster.
Next: One bus, multiple bus members