An easy one...

, , ,
1

Well, what I’m about to ask is something quite simple, that once I knew, but right now I’m not able to remember… :frowning: I feel almost guilty for not being able to remember. It’s a shame I know… :slight_smile:

The thing is. There are 2 (or more) ISs, connected through a broker. There are redundant services in both (all) ISs, which means, same packages, with same triggers subscribing documents (events), etc etc. Just for fault tolerance. If some IS falls down, other IS will eventually be up to execute the service. Yes, in fact we can even assume there are 2 identical IS, with identical services and so on, connected to the same broker.

Now, when a document is published, the broker would have two (as many as IS) clients, right? one from IS1, and another from IS2 subscribing that document. How should I do to be sure that only one of all the existent subscribes the document, and do the related job. I need only one, and only one to do it.

I know that the broker in fact do that, deliver to one of the current available clients of a document. but i cannot see right now how I can configure, either the document type, trigger or whatever to achieve that.

Because both things could be needed, i mean, to all the clients (IS) execute a work, or only one (and only one) execute the work. Where I can define that?

Regards and hope I made myself clear enough.

Thank you

2

You don’t need to do anything explicit other than make sure both IS instances use the same client prefix when connecting to the Broker.

The interaction between the IS and Broker will automatically process a particular document from a queue on just one IS.

There is a slight possibility that a particular document could get processed twice. This would be when one IS gets a document from Broker, successfully processes it but then fails before ack’ing to the Broker. In this case, the document would then be freed to be processed by another IS instance. While this is rare, you may want/need to account for dupes elsewhere in your processing.

“Because both things could be needed, i mean, to all the clients (IS) execute a work, or only one (and only one) execute the work.”

The latter behavior is the default when a document is published. To force a document to be sent to all IS instances, you’d need to deliver to each specific client ID of each IS instance. This isn’t a typical need. Indeed, the main point of a “broker client cluster” such as this is that the IS instances behave as if there is only one.