It depends on what you mean specifically by “2 subscribers.”
If you mean the same package and trigger on 2 different IS instances, and the instances use the same Broker prefix, then only 1 of those instances will process any given published event – from a Broker perspective (or UM) those are seen as the same subscriber. (Note: an IS cluster is not needed to accomplish this.)
If you mean 2 different packages, or even the same package but on 2 different IS instances using different Broker prefixes, then both will get all events – from a Broker perspective (or UM) those are seen as 2 different subscribers.
"If you mean the same package and trigger on 2 different IS instances, and the instances use the same Broker prefix, then only 1 of those instances will process any given published event – from a Broker perspective (or UM) those are seen as the same subscriber. (Note: an IS cluster is not needed to accomplish this.) "
I wanted to know , since for Broker , those are seen as same subscriber , then is there any criteria on basis of which it will be subscriber by one or the other.
OR is it any arbitrary random process, like any of the subscribers among two can subscriber it.
I mean the choice of any one IS instance among two depends on which criteria?
Is your query driven by a desire to confirm that a given message will be processed only once? Or to try to force a message to be received by a specific IS instance?
If the former, as long as the 2 IS nodes have the configuration described above (same Broker prefix, etc.) then messages will received by just one of the nodes. The only time that a message may be received/processed by both is in a failure situation. Consider this:
IS node 1 gets a message from Broker.
Before the ack is returned to Broker, IS node 1 fails or loses network connectivity.
Broker notices the lost connection, and that the event has not been ack’d. So it provides the message to the other node.
In my experience, this is exceedingly rare. Indeed, I cannot readily remember an instance of this occurring.
If your query is about forcing an event to a particular IS node, the short answer is that which node will receive a given message can be viewed as random/indeterminate. There is no way that I am aware of to force/control that a message be processed by one or the other IS instance.
Which IS instance will receive a given message depends on a number of factors, driven primarily by the trigger configuration. Serial vs concurrent, guaranteed vs volatile, refill size, ack queue size, etc. But ultimately, we have no way of knowing which node, nor of forcing a particular node.
The interaction between IS and Broker is such that only one IS instance will process a given message.