By Dave Cabelus, WebLogic Server Product Management
Recently, a customer asked me how MDBs interact with a Distributed Queue, especially after an Automatic Service Migration event occurs. We have some great technology built into WebLogic Server to make migration and failover seamless. I thought there might be some other folks interested in knowing more about this, too.
This blog assumes that you have some understanding of distributed queues and topics in WebLogic Server. To learn more about distributed destinations, see http://download.oracle.com/docs/cd/E17904_01/web.1111/e13738/advance_config.htm#i1079175.
The key to the behavior of MDBs in WebLogic Server is the relationship between the MDB Container and the JMS service. Between the two of them, there is a separation of complementary duties that make the end result possible. And when I say end result, I mean achieving the following goals:
- MDBs that service all members of a distributed queue: no orphaned members or messages
- Balanced load for both message production and message consumption
- Dynamic adaptation to changes in the WebLogic topology
The underlying premise behind MDB behavior is that an MDB that listens for messages on a distributed queue should adapt to changes in that distributed queue. Clusters, and thus distributed queues, are elastic in nature: cluster members can be added, cluster members can migrate from one host machine to another, and JMS services can migrate from one clustered managed server to another. MDBs need to be able to handle all of that elasticity without intervention.
Internally, there is a bit of a handshake and conversation between the JMS service in a cluster and the MDB container. When you deploy an application that contains an MDB that listens to a distributed queue, the MDB container asks the JMS service in the cluster for a list of the members in the distributed queue, and asks the JMS service to notify the MDB container if the membership changes in any way. Technically, the MDB container registers with a notification service for updates to the membership of the distributed queue. Updates include the coming and going of members and the location of each member. Changes can be caused by expansion of the cluster, failure of a server in the cluster, migration of a server in the cluster, or migration of a JMS service from one Managed Server to another. The MDB container reacts to these changes. The actual reaction depends on whether the distributed queue is hosted in the same cluster as the MDB (local case) or if it is hosted in a separate cluster (remote case).
When you deploy an application to a cluster, and the application includes an MDB that listens for messages on a distributed queue, the way that the MDB container manages the MDB depends on whether the distributed queue is local or remote. In either case, the MDB container does the right thing to achieve the goals mentioned above.
If the distributed queue is local – in the same cluster as the application deployment – the MDB container creates an MDB manager, or pool of MDBs, for each member of the distributed queue on each host where the distributed queue is running. The idea here is that you want to make sure that every member of the distributed queue is being serviced, and since the application is deployed to the same cluster, instances of the application should be available locally to do the job. If you have a homogenous configuration with a JMS Server on each managed server in the cluster and the distributed queue is targeted at the cluster, you will have one member of the distributed queue on each Managed Server in the cluster. The MDB container will create a pool of MDBs on each Managed Server to service each distributed queue member. Load balancing of messages across the distributed queue when they are produced will balance the load across the cluster.
Figure 1. Local MDBs and a Distributed Queue. The MDB container creates an MDB Manager wherever there is a Distributed Queue member.
If you add a Managed Server to the cluster with its own JMS server, the MDB container will react and create an MDB pool on the new server. The MDB container will learn about the new distributed queue member from the internal notification service.
Figure 2. Local MDBs and an expanded Distributed Queue. If the WebLogic cluster expands with a new Managed Server and JMS Server, the Distributed Queue expands to the new server and the MDB container creates a new local MDB manager.
Likewise, the MDB container will handle any migration scenarios where either a whole Managed Server migrates to a new location (Whole Server Migration) or the JMS service in a Managed Server migrates to another Managed Server in the cluster (Automatic Service Migration).
If the distributed queue is hosted in a cluster that is remote to the deployed application, the application needs to make sure that all members of the distributed queue are being serviced, and that the message consumers can react and adapt to changes in the distributed queue topology. The way the MDB container handles this is a little different than in the local case: For the remote case, the MDB container creates an MDB pool for each member of the distributed queue on each member of the cluster. The MDB container finds out about the distributed queue membership through the internal notification service. This same service will provide any updates in distributed queue membership to the remote MDB containers.
Figure 3. Remote MDBs and a Distributed Queue. The MDB container creates MDB pools for each Distributed Queue member.
This design ensures that the application listens for messages on all members of the distributed queue. If there are changes in the topology of the distributed queue – caused by cluster expansion, server failure, server migration, or JMS service migration – the JMS service will notify the MDB container and the MDB container will act on the notification.
Figure 4. Remote MDBs dynamically adapt to an expanded Cluster and Distributed Queue.
Both the JMS service and the MDB container in WebLogic Server do their part in providing the elastic capabilities and high availability for messaging in WebLogic Server. The JMS service hosts queues and topics, balances messages across a cluster, makes sure that all messages are routed and handled properly, and notifies the rest of the system of changes in the messaging topology. The MDB container makes sure that all members of a distributed destination are attended to, and that if there are changes in the topology of those destinations, the MDBs will adapt to those changes.
If you want more information, see the following documentation:
- Oracle WebLogic Product Page, then scroll down to the Enterprise Grid Messaging link in the Product Information section.