I'm trying to understand how to deal with the scenario where I have a subscriber to a topic, and the subscriber is running in a service that may exist as multiple instances (e.g., as in the case of being scaled up for handling extra load). Normally, each subscriber receives it's own copy of a message. In this case if I have say 3 instances of the service running I don't want each one to get their own copy. Instead, I would like to distribute the subscription across the set of instances, similar to how HTTP requests are handled by a load balancer.
One way I can see to do this is to define an administrative subscription on the queue manager that receives messages published to the topic, and then puts these on a queue (not topic). Then, change the clients to connect to the queue. Each instance of the client would get a message, thus preventing the same message from being handled by another instance. I'm wondering if there is a better way to do this that keeps with the original pub/sub model.
From what I've been able to read I believe this is referred to as a "shared durable subscription". This approach relies on the subscriber ID and client ID of each instance being the same. Does this require JMS? I found this approach mentioned in documentation for WAS ND (not MQ, itself).
With cloud deployment and automatic scaling by Kubernetes it seems this would be a common scenario to cover. I'm looking for the best pattern(s) for handling client scaling when you have multiple instances of the same client subscribed to a topic -- and the desire is to NOT have each client instance process the
same message.
Thanks,
Jim
------------------------------
Jim Creasman
------------------------------