Understanding Durable Subscribers in WebLogic JMS

Durable Subscriber:

A durable subscriber registers a durable subscription using a unique identity on a regular or a uniform distributed Topic. By default, a subscription is not durable i.e. a client’s subscription lasts as long as it has an active session. Any messages that are sent after a client gets disconnected are lost. A durable subscription ensures that the JMS consumer still can receive the messages destined for the topic, even after the connection to the JMS server has been disconnected. WebLogic will retain the messages in a JMS store for any subscriber that isn’t active when the messages were published and ensure that the unexpired messages are acknowledged by the subscriber when the client later reconnects.

Durable subscriptions mean that WebLogic server will store the messages in persistent store until it gets delivered to subscriber.

Who is the Subscriber?

Subscriber is the client application that connects to the JMS Topic to consume messages. For Example, an MDB (Message Driven Bean)

Who is the Publisher?

The Producer application that sends message to a Topic is known as the Publisher.

A durable subscription has no effect on the behavior of the subscriber or the messaging system while the subscriber is active (e.g., connected). A connected subscriber acts the same whether its subscription is durable or non-durable. The difference is in how the messaging system behaves when the subscriber is disconnected.

Need for the Durable Subscriber:

Durable Subscriber keeps track if the published message is being delivered to all topic subscribers. If one or more subscribers are not reachable at the time message was published, then the Durable Subscriber make sure to deliver the message when they become reachable.

Significance of Client ID in a Durable Subscriber:

Client Identifier is used on topic connection so as to uniquely identify the durable topic subscription. When a durable client reconnects to a topic, it’s the client id that lets the JMS server know that this is the same client that was previously connected. This enables the JMS Server to correctly determine those missed messages that should be sent to the topic subscriber

The standard approach is to assign a Client ID to a newly created Topic connection

connect = factory.CreateTopicConnection();

connect.setClientId(someUID);

Client IDs are supposed to be unique across connections. If a JMS client tries to set the client ID on two separate connections from a connection factory with no preset client ID, an InvalidClinetIDException should be thrown.

How to Create Durable Subscriber for a Regular Topic:

Create Durable Subscriber from Admin Console

• Login to Admin Console
• Navigate to Services > Messaging > JMS Module > Topic_Name > Monitoring > Durable Subscribers
• Click on New Button
• Provide Subscription Name and Client ID
• Click OK

Another way to create a durable subscriber on a regular topic is through the subscriber application and Message Driven Beans (MDBs) are one such example.
Setting following property in the MDB makes a durable subscription

@ActivationConfigProperty(propertyName = “subscriptionDurability”, propertyValue = “Durable”)

Durable Subscribers for Uniform distributed Topic

Durable subscribers cannot be created for uniform distributed topics directly from Admin console. The only way is to create durable subscription on each topic member from the subscriber application. 
Since the durable subscription is being created on the distributed topic member the subscriber application must use individual distributed topic member JNDI.

Consider a uniform distributed topic which has a jndi name as “disquota” is targeted to a cluster of two managed servers through JMSServer1 and JMSServer2 then the two distributed topic members have individual JNDI names as following:

• JMSServer1@disquota
• JMSServer2@disquota

Topic Subscription Identifiers

In WebLogic JMS, a subscription is identified and located based on 

1. the topic with which it is associated
2. the connection “Client ID” string 
3. if using durable subscriptions, the subscription name that is specified when the durable subscription is created. 
4. the Client ID Policy

If two WebLogic JMS subscription references on the same physical topic have the same Client ID and subscription name, then the references resolve to a single subscription if the Client ID Policy is also the same, but they resolve to two different subscriptions if the Client ID Policies are different.

How to Create Durable Subscription Using Message Driven Bean (MDB)

Use Case

1. Create a Regular Topic with JNDI as quota.
2. Create a Connection Factory with JNDI as confFact.
3. Target the Topic and the Connection Factory to a managed server.
4. Download and deploy the two subscriber applications TopicSubscriber1.jar and TopicSubscriber2.jar and target them to the same managed server as the Topic.
5. Download the attached standalone JMS client, TopicSend.java. Modify line# 89 for host and port. Run TopicSend.java to publish 5 messages to the topic.
6. Both the subscribers will consume all messages published to topic and following will be observed in the standard out of the managed server.

      7. Stop one of the subscriber applications from Admin console, stop TopicSubscriber1.jar.
      8. Run TopicSend.java to publish 5 messages to the topic.
      9. Subscriber TopicSubscriber2 will consume all 5 messages published to topic and following will be observed in the standard out of the managed server.

      10. Start the other subscriber application from Admin console and it will consume all messages published in step 7. Following will be observed in the standard out of the managed server.

Frequently Asked Questions

Q: Is it possible to create a Durable Subscriber for a JMS Queue?

A: No, Durable Subscriber is only applicable for Topics. A topic is a JMS artifact that allows multiple consumers to consume the same message. Durable Subscriber makes sure to deliver those messages to subscribers that were inactive when messages were published on the Topic.

Q. Does Durable Subscriber have max capacity size in Persistent Store? if so, what happens to messages when max capacity size is reached?

A. Max capacity size is not applicable to Durable Subscribers because they are created outside the Persistent Store. Persistent Store saves messages on the file system or in the database depending upon the type of Persistent Store however Durable Subscriber keeps track if the published message is being delivered to all topic subscribers. If one or more subscribers are not reachable at the time message was published, then the Durable Subscriber make sure to deliver the message when they become reachable.

Q. How long a message will be kept in the persistent store? Will it time out if the durable subscriber never comes back?

A.  JMS messages are kept in the persistent store, as long as the messages are not expired and/or JMS Server receives acknowledgement from all subscribers that the messages are delivered to all it’s subscribers.

Q. Do the messages persist only if the Topic has a Durable Subscriber?

A. Messages will be persisted only if the JMS Server that hosts the topic has the persistent store. Consider following use case:

1. Create a JMS Server that hosts a regular topic without a persistent store.
2. Create a durable subscription on this topic.
3. Publish few messages and the subscriber will get the published messages.
4. Stop the subscriber
5. Publish few messages on the topic
6. Shutdown the managed server where the JMS Server of that topic is targeted to.
7. Bring up the managed server, the messages published in step 5 will be lost because there was no persistent store.

Attachments:

TopicSubscriber1.jar

TopicSubscriber2.jar

TopicSend.java