Implementation of shared queue in broker 6.5.

Hi,

Let me tell my problem. I have two ISs connected to a single broker. Each IS has a document by name ‘empDoc’ and a trigger ‘empDocTrigger’ . I logged in to the Broker Admin page and found one document and only one client (…empDocTrigger). Now the actual problem is. I disabled the trigger on 1st IS and then published the document from 1st IS. but the document was not received by the trigger in the 2nd IS. This happens for vice versa also.

Expected behavior:

  1. When empDoc is published to the Broker, the document has to be consumed by either of the triggers.
  2. When one of the trigger is down then the other trigger should consume the documents.

Please let me know how can I achieve this.

Thanks in advance,
Rajkumar

What you describe is standard capability - two triggers, shared sessions on the same queue, concurrently consuming; one continues if the other is disconnected or the instance shuts down etc. So you can definitely do this and it is probably a question of configuration or operation. (FYI the Pub-Sub developer guide is well worth reading for this general area.)

You should check the Broker client prefix ID is the same for each IS in the Broker configuration (it probably is based on your description). You should have one Broker client but it should show two sessions.

You might also want to check how the triggers are behaving - I think originally in v6.5, if you disabled the trigger, especially if the IS was not configured as a genuine cluster, then one IS would unilaterally determine that since the trigger was disabled, the subscription was no longer valid and it would be removed.

This behaviour was updated/patched in the later service packs, but it is important to distinguish between disabling a trigger (turning off the subscription) and suspending a trigger (stopping processing). I believe there also used to be a bug in v6.5 some years back where the handling of multiple instances during shutdown of one or the other would result in temporarily lost subscriptions. Worth checking you are on the latest service pack with fixes relating to triggers.

There are now trigger services to suspend individual triggers on an IS (pub.triggers folder in WmPublic). This is very different from disabling the trigger in Developer and a better method for dynamic suspension of consumption.