Skip Headers
Oracle® Fusion Middleware Programming Message-Driven Beans for Oracle WebLogic Server
12c Release 1 (12.1.1)

Part Number E24977-02
Go to Documentation Home
Home
Go to Table of Contents
Contents
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

A Topic Deployment Scenarios

The following sections describe MDB deployment actions for various topic MDB configurations. The actions include where and how many MDB free pools are created, where and how many subscriptions are created, and how the subscribers work together to achieve a given messaging consumption pattern.

These sections do not cover details about legacy behavior which occurs when the topicMessagesDistributionMode is set to Compatibility, when the topics are foreign (non-WebLogic) topics, or when the topics are WebLogic JMS topics from WebLogic Server releases prior to 10.3.4.

For help determining the right scenario (permutation) for your application, including suggested settings, see Chapter 10, "Configuring and Deploying MDBs Using JMS Topics."

How Configuration Permutations Determine Deployment Actions

The following settings determine how WebLogic MDBs that consume from WebLogic JMS topics (from WebLogic Server 10.3.4 or later) create instances of MDB free pools, subscription naming, subscription locations, and how messages are distributed to those MDB pool instances:

Table A-1 describes possible configuration permutations and corresponding deployment actions. The first two columns describe the configuration permutations, and the last two columns describe the resulting deployment. The columns are as follows:

Table A-1 Configuration Permutations and Their Resulting Deployment Actions

MDB Configuration Deployment Actions
topicMessagesDistributionMode Topic Type Permutation Each Server Subscribes to... MDB Pools per Server

One-Copy-Per-Server

One of the local members

One

One-Copy-Per-Server

One of the remote members

One

One-Copy-Per-Server

  • PDT Local EveryMemberFoot 3 

  • PDT RemoteFootref 2

  • RDT Local EveryMember

  • RDT Remote (durable subscriptions only)Footref 2

  • Singleton WebLogic JMS (M=1)

All members

M

One-Copy-Per-Application

  • PDT Local LocalOnly

  • RDT Local LocalOnly

All local members

One per local member

One-Copy-Per-Application

  • PDT Local EveryMember

  • PDT RemoteFootref 2

  • RDT Local EveryMember

  • RDT RemoteFootref 2

  • Singleton WebLogic JMS (M=1)

All members

M


Footnote 1 The "One-Copy-Per-Server, RDT, Local, LocalOnly" permutation is not supported for durable subscription cases in some configuration topologies (See details in Scenario 1: Replicated DT, One Copy Per Server, Local Deployment, Local Only Consumption.)

Footnote 2 For remote distributed topics, WebLogic Server always creates subscriptions to every topic member except for non-durable subscriptions in the "One-Copy-Per-Server, Replicated Distributed Topic, Remote" permutation. In that case, only one subscription to one of the remote members is created. (See Scenario 3: Replicated DT, One Copy Per Server, Remote Deployment.)

Footnote 3 The LocalOnly setting is always automatically replaced with EveryMember in the "One-Copy-Per-Server, Partitioned Distributed Topic, Local" permutation. (See Scenario 7: Partitioned DT, One Copy Per Server, Local Deployment, Local Only Consumption.)

Typical Scenarios

The following sections show possible deployment scenarios of an MDB application:

Images and labels used in the figures presented in the scenarios are explained in Table A-2:

Table A-2 Explanation of Images and Text Used in Scenarios

Image or Text Explanation

Messages

Messages published to a distributed topic.

Double-headed arrow

Messages are duplicated, and copies are forwarded to other members of the topic. This indicates that the topics are replicated distributed topics.

DT Member n

Member of a distributed topic.

MDB Pool

An MDB free bean pool.

Single-headed arrow

A subscription. The MDB on one end of the arrow listens for and consumes messages from the topic on the other end of the arrow.

Box with three parts, S1, S2, S3

Shared subscription.

Box with three parts, S1, S2, S3

Non-shared subscription. S1 is Managed Server 1's subscription, S2 is Managed Server 2's subscription, etc.


Standalone (Non-distributed) Topic Scenarios

Standalone topic scenarios are as follows.

One-Copy-Per-Server

On each WebLogic Server instance that hosts the MDB application, an MDB pool is created for the topic, whether the topic is running in the same cluster or in a different cluster. For an MDB cluster of N nodes, N MDB pools are created. Each MDB pool creates an individual subscription on the topic, and subscribers from different MDB pools do not share the same subscription.

One-Copy-Per-Application

On each WebLogic Server instance that hosts the MDB application, an MDB pool is created for the topic, whether the topic is running in the same cluster or in a different cluster. For an MDB cluster of N nodes, N MDB pools are created. All subscribers created by the MDB pools of the same MDB application share the same subscription.

Replicated Distributed Topic Scenarios

With replicated distributed topics, all physical topic members receive each message sent. When a message arrives at one of the physical topic members, a copy of the message is automatically internally forwarded to the other members of the topic.

The following are the possible deployment scenarios for a replicated distributed topic:

Scenario 1: Replicated DT, One Copy Per Server, Local Deployment, Local Only Consumption

Figure A-1 shows the following configuration:

  • Replicated distributed topic

  • topicMessagesDistributionMode = One-Copy-Per-Server.

  • The MDB and the topic are deployed in the same (local) cluster.

  • distributedDestinationConnection = LocalOnly.

Figure A-1 Scenario 1: Replicated DT, One Copy Per Server, Local Deployment, Local Only Consumption

Description of Figure A-1 follows
Description of "Figure A-1 Scenario 1: Replicated DT, One Copy Per Server, Local Deployment, Local Only Consumption"

In this scenario:

  • Copies of messages are forwarded to other servers in the cluster by the RDT.

  • One MDB pool is created on each server in the local cluster.

  • Each MDB pool listens to one of the distributed topic member on the same server.

This approach can yield higher performance than "RDT, One Copy Per Server, Local Deployment, EveryMember," because all messaging is local (it avoids transferring messages over network calls) and still ensures that all distributed topic members are serviced by MDB consumers. However for some use cases, the EveryMember alternative may work better, based on the trade-offs discussed in Handling Uneven Message Loads and/or Message Processing Delays.

This scenario does not work correctly for durable subscriptions when there are multiple members on the same server, when there are no members on any of the local servers that host the MDB application, or when JMS service migration (auto or manual) is involved.

Scenario 2: Replicated DT, One Copy Per Server, Local Deployment, Every Member Consumption,

Figure A-2 shows the following configuration:

  • Replicated distributed topic

  • topicMessagesDistributionMode = One-Copy-Per-Server.

  • The MDB and the topic are deployed in the same (local) cluster.

  • distributedDestinationConnection = EveryMember.

Figure A-2 Scenario 2: Replicated DT, One Copy Per Server, Local Deployment, Every Member Consumption

Description of Figure A-2 follows
Description of "Figure A-2 Scenario 2: Replicated DT, One Copy Per Server, Local Deployment, Every Member Consumption"

In this scenario:

  • Copies of messages are forwarded to other servers in the cluster by the RDT, but these copies are filtered out (ignored) by the MDB subscriptions.

  • An MDB pool is created for each distributed topic member on each server in the local cluster.

  • Each MDB pool listens to one of the distributed topic members in the cluster.

  • Each WebLogic Server instance that hosts the MDB application listens to all members of the distributed topic.

  • Each server's subscribers on the same member of the DT have their own independent subscriptions. In other words, subscribers from different servers to the same member do not share any subscriptions.

This configuration yields high flexibility and is good for an application where an RDT is required, but it cannot be guaranteed that there will be exactly one member per server, for example due to migration.

This configuration does not give the best performance in comparison to Scenario 1: Replicated DT, One Copy Per Server, Local Deployment, Local Only Consumption, especially for a static environment where no migration is involved and there is one and only one member of the distributed topic on each managed server. Applications where no migration is involved and where there is one and only one member of the distributed topic on each managed server can use Scenario 1.

Scenario 3: Replicated DT, One Copy Per Server, Remote Deployment

Figure A-3 shows the following configuration:

  • Replicated distributed topic

  • Durable subscription

  • topicMessagesDistributionMode = One-Copy-Per-Server.

  • The MDB and the topic are deployed in different (remote) clusters.

  • distributedDestinationConnection ignored for remote deployments.

Figure A-3 Scenario 3: Replicated DT, One Copy Per Server, Remote Deployment

Description of Figure A-3 follows
Description of "Figure A-3 Scenario 3: Replicated DT, One Copy Per Server, Remote Deployment"

In this scenario:

  • Copies of messages are forwarded to other servers in the cluster by the RDT, but these copies are filtered out (ignored) by the MDB subscriptions.

  • An MDB pool for each distributed topic member is created on each server in the remote cluster.

  • Each WebLogic Server instance that hosts the MDB application listens to all members of the distributed topic (one local pool for each remote member).

  • Each server's subscribers on the same member of the DT have their own independent subscription. In other words, subscribers from different servers to the same member do not share any subscriptions.

Note that this is the behavior for durable cases. For non-durable cases, each WebLogic Server instance creates a single MDB pool which connects to one of the members (any member) as an optimization.

Scenario 4: Replicated DT, One Copy Per Application, Local Deployment, Local Only Consumption

Figure A-4 shows the following configuration:

  • Replicated distributed topic

  • topicMessagesDistributionMode = One-Copy-Per-Application.

  • The MDB and the topic are deployed in the same (local) cluster.

  • distributedDestinationConnection = LocalOnly.

Figure A-4 Scenario 4: Replicated DT, One Copy Per Application, Local Deployment, Local Only Consumption

Description of Figure A-4 follows
Description of "Figure A-4 Scenario 4: Replicated DT, One Copy Per Application, Local Deployment, Local Only Consumption"

In this scenario:

  • Copies of messages are forwarded to other servers in the cluster by the RDT, but these copies are filtered out (ignored) by the MDB subscriptions.

  • One MDB pool is created on each server in the local cluster for each local member (Figure A-5 shows a configuration where each WebLogic Server instance hosts only one member. When there are multiple members on the same local WebLogic Server instance, multiple MDB pools are created on the server).

  • A message is given to only one MDB pool.

  • All subscribers on the same member share the same subscription.

Scenario 5: Replicated DT, One Copy Per Application, Local Deployment, Every Member Consumption

Figure A-5 shows the following configuration:

  • Replicated distributed topic

  • topicMessagesDistributionMode = One-Copy-Per-Application.

  • The MDB and the topic are deployed in the same (local) cluster.

  • distributedDestinationConnection = EveryMember.

Figure A-5 Scenario 5: Replicated DT, One Copy Per Application, Local Deployment, Every Member Consumption

Description of Figure A-5 follows
Description of "Figure A-5 Scenario 5: Replicated DT, One Copy Per Application, Local Deployment, Every Member Consumption"

In this scenario:

  • Copies of messages are forwarded to other servers in the cluster by the RDT, but these copies are filtered out (ignored) by the MDB subscriptions.

  • One MDB pool is created on each server in the local cluster for each member.

  • A message is given to only one MDB pool.

  • All subscribers on the same member share the same subscription.

Scenario 6: Replicated DT One Copy Per Application, Remote Deployment

Figure A-6 shows the following configuration:

  • Replicated distributed topic

  • topicMessagesDistributionMode = One-Copy-Per-Application.

  • The MDB and the topic are deployed in different (remote) clusters.

  • distributedDestinationConnection ignored for remote deployments.

Figure A-6 Scenario 6: Replicated DT, One Copy Per Application, Remote Deployment

Description of Figure A-6 follows
Description of "Figure A-6 Scenario 6: Replicated DT, One Copy Per Application, Remote Deployment"

In this scenario:

  • Copies of messages are forwarded to other servers in the cluster by the RDT, but these copies are filtered out (ignored) by the MDB subscriptions.

  • One MDB pool is created on each server in the local cluster for each member in the remote cluster.

  • A message is given to only one MDB pool.

  • All subscribers on the same member share the same subscription.

Partitioned Distributed Topic Scenarios

With partitioned topics:

  • The distributed topic member receiving the message is the only member that is aware of the message. The message is not forwarded to other members, and subscribers on other members do not get a copy of the message.

  • Incoming messages can be load balanced among the distributed topic members using the JMS Affinity and Load Balance attributes. See "Load Balancing Partitioned Distributed Topics" in Configuring and Managing JMS for Oracle WebLogic Server.

The following are the possible deployment scenarios for a partitioned distributed topic:

Scenario 7: Partitioned DT, One Copy Per Server, Local Deployment, Local Only Consumption

The setting of distributedDestinationConnection is ignored for this scenario and a warning message is logged. The setting is forced to EveryMember instead. The behavior becomes the same as the "EveryMember" case (see "Scenario 8: Partitioned DT, One Copy Per Server, Local Deployment, Every Member Consumption").

Scenario 8: Partitioned DT, One Copy Per Server, Local Deployment, Every Member Consumption

Figure A-7 shows the following configuration:

  • Partitioned distributed topic

  • topicMessagesDistributionMode = One-Copy-Per-Server.

  • The MDB and the topic are deployed in the same (local) cluster.

  • distributedDestinationConnection = EveryMember.

Figure A-7 Scenario 8: Partitioned DT, One Copy Per Server, Local Deployment, Every Member Consumption

Description of Figure A-7 follows
Description of "Figure A-7 Scenario 8: Partitioned DT, One Copy Per Server, Local Deployment, Every Member Consumption"

In this scenario:

  • Messages are distributed individually to the distributed topic members. Messages are not duplicated or copied to other members in the cluster.

  • An MDB pool is created for each distributed topic member on each server in the local cluster.

  • Each server's subscribers on the same member of the DT have their own independent subscription. In other words, subscribers from a particular server to the same member do not share any subscriptions with subscribers from another server.

Scenario 9: Partitioned DT, One Copy Per Server, Remote Deployment

The details of this scenario are the same as the previous one except that the MDB deployment and the PDT are in different clusters.

Scenario 9: Partitioned DT, One Copy Per Application, Local Deployment, Local Only Consumption

Figure A-8 shows the following configuration:

  • Partitioned distributed topic

  • topicMessagesDistributionMode = One-Copy-Per-Application.

  • The MDB and the topic are deployed in the same (local) cluster.

  • distributedDestinationConnection = LocalOnly.

Figure A-8 Scenario 9: Partitioned DT, One Copy Per Application, Local Deployment, LocalOnly Consumption

Description of Figure A-8 follows
Description of "Figure A-8 Scenario 9: Partitioned DT, One Copy Per Application, Local Deployment, LocalOnly Consumption"

In this scenario:

  • Messages are distributed individually to the distributed topic members. Messages are not duplicated or copied to other members in the cluster.

  • One MDB pool is created on each server in the local cluster for each local member (Figure A-9 shows a configuration where each WebLogic Server hosts only one member. When there are multiple members on the same local WebLogic Server, multiple MDB pools are created on each WebLogic Server instance).

This scenario is the recommended configuration for One-Copy-Per-Application and Local PT for high performance. However for some use cases, the EveryMember alternative may work better, based on the trade-offs discussed in Handling Uneven Message Loads and/or Message Processing Delays.

Scenario 11: Partitioned DT, One Copy Per Application, Local Deployment, Every Member Consumption

Figure A-10 shows the following configuration:

  • Partitioned distributed topic

  • topicMessagesDistributionMode = One-Copy-Per-Application.

  • The MDB and the topic are deployed in the same (local) cluster.

  • distributedDestinationConnection = EveryMember.

Figure A-9 Scenario 11: Partitioned DT, One Copy Per Application, Local Deployment, Every Member Consumption

Description of Figure A-9 follows
Description of "Figure A-9 Scenario 11: Partitioned DT, One Copy Per Application, Local Deployment, Every Member Consumption"

For a partitioned distributed topic, one copy per application, local deployment, it is better to use LocalOnly consumption for most use cases, as shown in Scenario 9: Partitioned DT, One Copy Per Application, Local Deployment, Local Only Consumption. However the trade-offs discussed in Handling Uneven Message Loads and/or Message Processing Delays, apply here.

Scenario 12: Partitioned DT, One Copy Per Application, Remote Deployment

Figure A-10 shows the following configuration:

  • Partitioned distributed topic

  • topicMessagesDistributionMode = One-Copy-Per-Application.

  • The MDB and the topic are deployed in different (remote) cluster.

  • distributedDestinationConnection ignored for remote deployments.

Figure A-10 Scenario 12: Partitioned DT, One Copy Per Application, Remote Deployment

Description of Figure A-10 follows
Description of "Figure A-10 Scenario 12: Partitioned DT, One Copy Per Application, Remote Deployment"

In this scenario:

  • Messages are distributed individually to the distributed topic members. Messages are not duplicated or copied to other members in the cluster.

  • Subscriptions are created on all the distributed topic members automatically and dynamically.

  • A message is given to only one MDB pool.

  • All subscribers from the same MDB application on the same member share the same subscription.