Singleton processing of topic subscription

,
1

Hi,

I have a requirement to have multiple subscribers register for a specific topic, but I want only ever want just one of these subscribers to handle the event.

Is that possible in Web Methods? I am using the Broker implementation.

Thanks,

Stan

2

Hi Stan,

Yes. You can do that.

Assuming you mean to use only one shared durable subscriber and multiple clients connected to it to process the messages in load balancing way. In this case, only one of the connected client will get the message and process it and you don’t need to do anything special except setting client id sharing for connection. Refer to WmJMSConfig.setClientIDSharing(true) for more details. In this case, you will end up with a single durable subscriber (say Topic##Sub) that is getting connected from multiple client applications and only one of the client application will process the message.

If you are actually using multiple subscribers, e.g. Topic##Sub1, Topic##Sub2, etc, then spec compliant way is to use filters to ensure that only one durable subscriber gets the event.

But, using too many filters have performance penalty. Broker core functionality just has a simple queue implementation that supports both deliver to a specific queue as well as publish to all subscribing queues. So, technically it is possible to have Topic##Sub1 and Topic##Sub2 and then use send API to queue to message to only one of the queue. Something like using MessageProducer.send(queue,message) instead of using TopicPublisher.publish(message) where queue variable is not actually a JMS Queue but points to specific JMS Durable Subscriber. This will be hackish way, and it certainly will work if you start using Broker implementation classes instead of standard JMS interfaces. This will be last approach, when you must use multiple durable subscribers and don’t want to have filter performance penalty too.

3

Hi Sandeep,

Once again - thanks. Just to make sure I have the correct wording:

You wrote:

“Assuming you mean to use only one shared durable subscriber and multiple clients …”

Did you mean:

“Assuming you mean to use only one shared durable subscription and multiple clients …”

Also…

When setting the connection ID sharing, is this something I do from the client, or is this done in the configuration on the server? Also, my clients run in their own processes - is this sharing still possible?

Thanks,

Stan

4

Hi Stan,

Yes. subscription looks better word. So “Assuming you mean to use only one shared durable subscription and multiple clients …”
There is one subscription, so Topic Message is queued up once to the subscription, and multiple clients share the message processing load.

“Connection Client Id Sharing”
Yes, this is client side setting. Default is set to false.
And, yes, multiple process can use this setting.
You will need to do one of following:

  1. Set Java property ‘com.webMethods.jms.clientIDSharing=true’ at program startup.
  2. Call static method ‘WmJMSConfig.setClientIDSharing(true)’ that gets called during startup.
  3. Set ‘com.webMethods.jms.clientIDSharing=true’ in a file called ‘wmjms.properties’. Modify the classpath to include the directory containing the property file. Or, you could put the file in ‘wm-jmsclient.jar’.
    People usually use 1 & 2 which is cleaner, straightforward, and customization is easily visible.

High level steps will be:

  1. Create Topic with ‘sharedState=true’, ‘sharedShateOrdering=None’ on JNDI.
  2. Create a ConnectionFactory with clientID on JNDI
  3. Create Durable Subscriber on Broker using Topic and Connection Factory.
  4. Run you client applications with client ID Sharing enabled. Only one of those client will process a specific message, and all of them will share the message load.
5

Hi Sandeep,

Thanks once more. I just need to map this to C - which the language of my client. I have have seen similar descriptions in the C programing guide.

You have been of great assistance!

Regards,

Stan

6

Hi Stan,

If you are using C, then things are simpler. There is a Document Type or Event Type (defines the meta data of event) and Client Queue (defines the queue to store enqueued events), you can mix and match then in any combination.

I think you will need to do something like following:

  1. Create a Document Type in Broker using Administration UI.
  2. Create new Client Group or modify an existing one.
  3. Grant can pub, can sub permissions of defined Document Type to Client Group in Broker using Administration UI.
  4. Create multiple Broker Client using same ‘clientId’ using a ‘ConnectionDescriptor’ setting ‘stateShare’ and ‘stateShareOrdering’. They all will connect to same queue and share the message load. Check the C programmers guide for exact terms/structures.

I stayed specific to JMS as we used term topic subscribers. By any chance you are mixing C and JMS clients?

1 Like
7

Hi Sandeep,

Thanks once again - no all ‘C’.

Regards,

Stan

8

Hi Sandeep,

Thanks. I have all of this working now. You are a life-saver!

Regards,

Stan

1 Like
9

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.