Durable topics persist messages so that if a subscriber is not online, it can receive the messages later. A durable topic subscription is useful when a subscriber client needs to be able to receive messages that are published even when the client is inactive.
Managing durable topic subscriptions
If a client subscriber creates a durable subscription to the topic, the subscriber will be able to recover the messages that were published to the topic while the client was inactive. For example, a durable topic subscriber will receive all the messages that are published to the topic while the subscriber is active. However, if the subscriber becomes inactive for a time period and later returns to active state, the messages that were published during the inactive period will be fetched from the database and dispatched to the subscriber.
The following points will elaborate on the different elements that you need to be mindful of when creating a durable topic subscription:
Creating a durable topic subscription is similar to creating a nondurable subscription, but you must additionally provide a name that identifies the durable subscription as shown below.
The session used to create a durable topic subscriber must have an associated client identifier. The client identifier can be specified by setting the CLIENTID property of the ConnectionFactory object. The client identifier associated with a session is the same as that associated with the connection that is used to create the session as shown below. The name that identifies a durable subscription must be unique only within the client identifier, and therefore the client identifier forms part of the full, unique identifier of the durable subscription.
For example, shown below is how the ClientID is set for an amqp session:
Alternatively, an application can specify the client identifier by calling the
setClientID()method of the Connection object. For more information about client identifiers and their relationship with durable topic subscribers and durable subscriptions, see Java™ Message Service Specification, Version 1.1.
- Reusing a durable topic subscription: To reuse a durable subscription that was created previously, the subscriber client must create a durable topic subscriber using a session with the same client identifier as that associated with the durable subscription.
Tenant-specific durable subscriptions
When creating a JMS subscription in tenant mode, the username, topic name and subscription ID should be set in the following manner:
Example: username =testuser!test.com;
topicName = tenantdomain/topicName;
Example: topicName = test.com/testTopic;
subscription Id=tenantdomain/subscription id
Example: subscription Id=test.com/K1;
Managing nondurable topic subscriptions
Nondurable message consumers in the publish/subscribe domain automatically deregister themselves when their
close() method is called or when they fall out of scope. However, if you want to terminate a durable subscription, you must explicitly notify the broker. To do this, use the
unsubscribe() method of the session and pass in the name that identifies the durable subscription:
It is not possible to unsubscribe a durable consumer from inside the
onMessage() method in the listener. If you need to unsubscribe, write a separate class/thread etc. with a different session, give the subscription ID and unsubscribe.
Sharing a durable topic subscription
As explained in the previous section, durable topic subscriptions are unique. That is, the subscription ID and client ID, which are used for identifying the durable subscription should be unique. This means that it is not possible to have multiple subscriber clients sharing a single subscription. Consider the following scenario:
In the above example, there are two subscribers (A and B) with durable subscriptions to the topic and each subscriber performs a specific task with the messages received through the subscription. Therefore, when messages are published to the topic, copies of the messages are dispatched to both subscribers and each subscriber will perform a unique task. This is how the default configuration of WSO2 MB works. You will note here that it is not possible to have two subscriber clients performing the same task. For example, consider that the task that should be performed by subscriber A is time consuming and requires a lot of CPU memory. In such a situation, we need to be able to scale the work load of subscriber A among multiple subscriber clients. The following diagram depicts this requirement:
As shown above, what we need is to establish a single subscription where the messages received are shared by multiple subscriber clients using the round-robin method. In the default set up of WSO2 MB, this is not possible, because when there are multiple subscriber clients connecting to the topic, copies of the same messages are dispatched to all the subscriber clients. Therefore, sharing a subscription is only possible if the subscription ID can be shared by all the subscriber clients.
You can enable shared topic subscriptions in WSO2 MB by following the steps given below.
- Open the
broker.xmlfile stored in the
allowSharedTopicSubscriptionselement as shown below. Note that this property is only applicable to AMQP.
- The JMS clients that are subscribing to the topic should create durable subscriptions using the same subscription ID. See the previous section on creating durable topics subscriptions.