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 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)
Figure 2. Application instances that use individual subscriptions (messages fanned out)
For point-to-point messages, we can use queue destinations and partition a queue so that messages are workload balanced. However, we 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, we 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, we 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 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.
We 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.
Related: