Hi,

I am having great difficulty in creating Durable Subscribers in UM v9.9

Via the UM Enterprise Manager, there is no way to create a Durable Topic. You can only create a ‘Topic’.

The only way I have found possible to create a durable subscriber is via Designer. When creating a new Trigger, when I select the Destination Name, there is the ability to Create New Destination. This allows the option of selecting a Durable Topic - it appears both the Trigger and the Topic must be ‘Durable’.

All looks good at that point in Designer.

However, if I populate the KEY field, the new Durable Topic is not visible in UM Enterprise Manager.
It is visible via the JNDI lookup. But I am unable to send messages to that queue.

If I don’t populate the KEY field, it is visible in both and appears to function ok. I can send messages to that queue.

My question is - what is best practice for creating Durable Subscribers / Topics? It doesn’t appear to be documented anywhere and I am surprised it is not possible via the UM Enterprise Manager. It is not even possible to see if a Topic is Durable (unless you put it in the name).

Thanks,

Steve

It’s not possible via the UM enterprise manager , what you have done is the correct way of creating durable subscribers. Durable subscribers are named queues associated with a topic.

Destination Name :- The name of queue/topic present on UM
Destination key :- The name of the JNDI key with which lookup for the destination will happen , generally the best practice , what I have seen is to keep the destination name and destination key same(to avoid confusion).
Destination type :- Type of destination you want to create on the UM i.e. Queue/Topic/Topic(Durable)
Durable Subscriber :- It is the named queue associated with the topic , you cannot create durable subscriber for queue as it is already durable.

Hi Rakesh,

Thanks for clarifying that UM Enterprise Manager cannot create Durable Topics. It must be done via Designer.

Thank you also for detailing what those fields mean, as I could not find it documented anywhere. I looked high and low.

Just to clarify:

Destination Name - the name of the NEW topic I am creating (eg it doesn’t exist at the moment)
Destination Key - same as Destination Name
Destination Type - Topic(Durable)
Durable Subscriber Name - Would this be the same as Destination Name / Key? This is what appears in the Named Objects part of UM Ent Mgr for the Durable Topic. How important is this value, and does it need to align with anything else?

Thanks again,

Steve

Your understanding is correct.

For durable subscriber you can keep any name you want , durable subscriber is used to prevent the loss of messages when the subscriber is down.
But it’s better to have some naming convention around it. Like TopicName_DurSub

https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files/4e12a641e437252c8c0925f2c3d53d3e1ded4e10.png 1.5x, https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files/4e12a641e437252c8c0925f2c3d53d3e1ded4e10.png 2x" data-dominant-color="CDD6DF">

DurableSubscriber.PNG926×128 13.2 KB

While it is possible to create this through Designer, there is no reason not to achieve this through Enterprise manager. You can create a Topic connection factory that is shared and durable via Enterprise manager & Topic created inside this CF should allow it to be a ‘shared durable’… Can you check this?

-Senthil

There seems to be a little confusion going on here, so hope this will clarify:

CREATING TOPICS
You can create topics either using Designer (from the Trigger panel) or in Enterprise Manager (from the JNDI panel). Any topics created through either of these ways can be used by both durable and non-durable subscribers.
A topic has an actual channel name and a lookup name. Topics created through EM will have the same name for both (you can only enter one name). Topics created in Designer CAN have a different channel name and lookup name, but I highly recommend keeping them the same (to avoid confusion and ease troubleshooting).

DURABLE SUBSCRIPTIONS
These are established on a topic when a subscriber wants the server to store messages sent while the subscriber is offline, so that they can be delivered when it comes back online. You cannot and do not need to explicitly create these. Simply specifying a durable subscriber name in the IS JMS trigger will ensure that it is create when the trigger first connects. Durable subscriptions are visible in EM as Named Objects associated with the relevant channel for the topic.
The name of the named object is a concatenation of the DS name specified in the trigger and the client ID specified in the IS JMS alias. So different triggers subscribing to the same topic that both want to receive each message must specify different DS names. Two ISes working together where you want each message to reach only one IS, must use the same client ID on both ISes.

SHARED DURABLE CONNECTION FACTORY
The JMS spec does not allow multiple subscribers to consume from the same DS. However, with IS we often want to use multi-threaded triggers, or multiple ISes to share the load of processing messages. In order to allow UM to “breach” this JMS spec, you need to establish your JMS connection using a Shared Durable Connection Factory. This is a normal CF, but will tell UM to allow concurrent access to DSes. You will need this is you are using a concurrent trigger in IS, and/or multiple ISes. I would generally recommend always using a shared durable CF - for the sake of simplicity.
Note: A Shared Durable CF behaves exactly the same as a normal CF for queue subscribers and non-durable topic subscribers.

Hi Jonathan,

Thank you very much for your detailed explanation. Coming from years of experience using Broker, some of the JMS concepts are new to me. I understand them much better now - hartelijk dank.

One remaining query I have is this:

If I create a Topic, and have non-durable subscribers in a clustered environment using the same clientId, I find that both nodes will get a copy of the message. Eg both triggers fire. If I only want one trigger to fire, I need to use Durable Subscribers. I have experienced this in two seperate installations of v9.9 platform so I am thinking this is expected behaviour. Could you please confirm?

Cheers,

Steve

Steve,

That is expected behavior and would be the same with Broker, UM or any JMS provider. Note that the client ID in the JMS alias plays not part in a non-durable topic subscription, so each IS will be treated as a separate subscriber and each will receive a copy of each message on the topic.