We have a scenario where there are 2 x IS servers clustered (V9.0).
They are connected to one UM server which is clustered in Active/Passive, so only one UM node is up and running at any one time.
We have a Queue for posting messages.
When we post a message to the Queue (via pub.jms:send), both JMS triggers fire - one on each of the IS nodes in the cluster.
This is not what we would like to happen. As per with JMS on Broker (prior to UM), the IS would handle this and only one trigger would fire.
I have tried setting the Exactly Once processing to True and also Use History (document history JDBC pool is configured) but it always fires twice.
This may be a silly question, but is this expected behaviour? I would expect a clustered IS environment to be able to handle this in some manner. Otherwise load balancing is not possible. I have scoured the web looking for information but have not found anything that satisfies my query.
I am now seeking the intelligence of the community! Many thanks in advance for your help.
Non-shared durable: A non-shared durable subscription may have only one active (i.e. not closed) consumer at any given time.
Shared durable: A shared durable subscription is used by a client that needs to be able to share the work of receiving messages from a durable subscription amongst multiple consumers. A shared durable subscription may therefore have more than one consumer. Each message from the subscription will be delivered to only one of the consumers on that subscription.
Durable subscribers can be defined only for topics; they are not available for queues.
I checked my connection factory in UM and Shared Durable is ticked.
Is the problem that I am using Queues and not Topics? I am using a Queue as this info is point-to-point and will not be shared.
Is it not possible to have a Shared Consumer on a Queue?
In the meantime i will setup a Topic and see if I get the same behaviour.
I found that if I create Durable Subscribers/Topics, only ONE node will pick up the document. This solves my immediate problem, as there is only one subscriber.
However it means that I am unable to have multiple (different) subscribers. Eg I may want to publish an Order document to a topic and have multiple subscribers to it for different purposes. The whole premise of using Topics and pub/sub.
Does anyone know how to allow multiple subscribers to the same topic that call different services?
I would have thought this stuff was bread and butter for UM / JMS. Surprised I am having issues with the latest version of UM, unless I am doing something wrong.
For different trigger you can use different durable subscriber and each durable subscriber will be able to receive a copy of the message you publish on the topic.
Coming back to your original question related to queue , if the connection alias is same on the both the IS nodes , only one IS should get the message posted on the queue. If you are finding any deviation from this behavior , please raise a ticket with the SAG support team as it might be a bug.
The extra subscriber I made was indeed Durable, just like the other ones. But no luck. In fact I noticed that when I did a JMS send, it wasn’t always the same trigger that fired. Sometimes the new one did. But never both, which is the outcome I am looking for.
I will raise this to SAG as I believe it is not behaving as it should.
I would expect Durable Subscribers to each get a copy of a message on a Topic (on one node only if clustered).
When you said you have a different subscriber(made to be durable) which should listen to same topic, then did you mention different durable subscriber name for the new subscriber(trigger)?
Hopefully this will help clarify things:
QUEUES - The JMS alias client ID is not important for queue subscribers, neither is the Shared Durable setting of the ConnectionFactory. If you are seeing each message processed twice, then that is not expected behavior with a queue, if both triggers are subscribing to the same queue. The only thing to check would be the acknowledgment mode of the IS JMS trigger. You can find these modes documented in the Designer Service Development help.
TOPICS - Use durable subscriptions to ensure guaranteed processing of messages sent to a topic. The durable subscriber name in UM is a combination of the durable subscriber name in the IS trigger and the client ID specified in the IS JMS alias. So if you have the same trigger deployed to two ISes and you want only one of them to process each message, then make sure the client IDs are the same. If you want an additional subscriber to call a different service (so that both subscribers get each message), then simply ensure the durable subscriber name in the second IS trigger is different from the first trigger.
If you are seeing different behavior from this, then I suggest you raise a support request with Software AG Global Support.