UMS Integration Server Support for Load balanced JMS Client for JMS Topic Not working

, ,
1

Hi There,

Client is trying to use JMS Topic on UMS with Clustered Integration server as its JMS client. Solution requires once only processing of messages .

I’ve had a look at product document release-notes-9.5.2 (available under /nirvana/doc. These documents confirms support for Shared Durable subscription.

Shared Durable Subscription
Universal Messaging 9.0 introduces the concept of Shared Durable subscriptions. Durable subscriptions are topic based, meaning that all events on a topic are delivered to all consumers, however only one active consumer
is typically permitted to bind itself to a durable subscription name. In Universal Messaging 9.0 there is now the ability for multiple active subscribers to bind to a subscription name, and each message will be delivered to only one of these consumers.

POC however throws up very different behaviour.

POC Detail
# Components:

  • JMS Topic Connection Factory, Shared Durable Topic Connection Factory, Connection Factory, JMS Topic on UMS.
  • JMS Connection Alias in Integration Server to use one or the other connection factory defined in step above.
  • Flow service to publish JMS messages using pub.jms.send
  • Two JMS Trigger listening for message with processing set to concurrent but max 3 thread. Durable subscriber name is same for both triggers listerning on same JMS Topic.
  • Flow service that both JMS trigger would invoke and pass on the JMS Message
    # Implementation logic
  1. Topic Connection Factory
  • If Topic Connection Factory is used to create JMS Connection alias in IS, UMS prevents 2nd trigger from registering due to duplicate durable subscriber name.
  • Which is understandble.
  1. Connection Factory
  • Same behaviour as above and understandable.
  1. Shared Durable Topic Connection Factory
  • Both triggers can be enabled and register with UMS JMS with no errors.
  • JMS Trigger is then disabled to stop the messages from being processed. This would allow 1st Flow service above to publish some JMS messages with MSG ID (incremental number in Body payload) to identify uniqueness of it.
  • Via UMS Enterprise Manager, I can spool on JMS Topic to see that messages are all waiting and that they have correct MSG ID as per service publishing it.
  • I then go in and enable trigger which invokes flow service which logs the JMSMessage/body/data/MSGID field from message using debugLog.
    # Observation
  • With Shared Durable TCF, Both subscription trigger seem to receive same messages and as many times as number of threads. This causes duplication at multiple level 1. at both trigger levels 2. at per thread per trigger level.
  • With Standard TCF, if only one trigger is enabled, but has concurrent processing with more than one thread is set up, IS receives error related to duplicate durable subscriber when trigger tries to process more than one message. in effect one thread works fine but all other thread fails to receive and process message. Concurrent processing is not supported as a result.

Can you please advice if I’ve missed anything or that problem is with product? I can then advice client accordingly.

Regards,
Ashish