Workload sharing with publish/subscribe messaging

In publish/subscribe messaging, the messaging system sends one copy of every published message to each matching subscription. Subscribers, that is, applications that consume publish/subscribe messages, consume those messages from an individual subscription. To balance workload across multiple instances of an application, for example when an application runs in a server cluster, all instances of the application must use the same subscription.

Figure 1 shows that, in this configuration, only one instance of the application processes each message that is sent to the subscription. However, Figure 2 shows that if different instances of the same application are configured to receive messages from different subscriptions, each instance processes a copy of every matching message, so that each message is spread (fanned) out.

Figure 1. Application instances that share a single subscription (workload sharing)
Three messages from a publisher go to a single subscription, then each message goes to only one of three separate application instances.
Figure 2. Application instances that use individual subscriptions (messages fanned out)
Three messages from a publisher all go to three subscriptions, then all three messages go to each of three separate application instances.

For point-to-point messages, you can use queue destinations and partition a queue so that messages are workload balanced. However, you cannot partition subscriptions in this way.

For publish/subscribe messaging, to configure multiple application instances to use the same subscription, and therefore balance the message workload, you must use a durable subscription. The multiple instances of the application must be able to consume simultaneously from the same subscription. This type of subscription is called a shared durable subscription. To configure a shared durable subscription, you set the Share durable subscriptions property for the relevant connection factory or activation specification.

A durable subscription has a home messaging engine and a unique identity, which is formed from the client identity and the subscription name. The messaging system can accumulate new matching publications for the subscription even while there is no active subscriber. The home messaging engine accumulates messages for a subscription by using a publication point. When a subscriber starts or restarts, the messaging system uses the unique identity and the home messaging engine to identify the publication point, locate the durable subscription, and deliver any accumulated messages.

A nondurable subscription does not have a unique identity. It lasts for the lifetime of its subscriber. Multiple application instances cannot receive messages from the same nondurable subscription.

You can set the Shared durable subscription property to one of the following:
In cluster
The bus distributes work between clients that connect to a bus member in the same cluster when the clients use the same client identifier and durable subscription name.
Always shared
The bus distributes work between clients, regardless of where they connect to the bus, when the clients use the same client identifier and durable subscription name.
Never shared
Clients cannot use the same client identifier and durable subscription name as an existing session.

Icon that indicates the type of topic Concept topic



Timestamp icon Last updated: March 5, 2017 17:24
File name: cjt0015_.html