I am using pub.trigger:resumeProcessing, and pub.trigger:suspendProcessing services in cases of outages and cutover tasks. The idea is to stop documents to flow to target, yet pile up at the broker.

After a day (almost 24 hours), these trigger valves automatically opens up (IS or Broker is NOT restarted) and documents flows through. Anybody have a work around ?

Meanwhile, I am using Developer to disable trigger but I do NOT like it (“it” is the code change in Production).

Any ideas ?

Rocky

What version of Integration Server are you using?

Integration Server 6.5 includes a “Trigger Management” secton on the Admin console (see Settings > Resources > Trigger Management). This can be quite helpful, as you have complete control over any trigger without having to write, modify, or even call custom flow services or code.

Please note that you would probably rather call “suspendRetrieval” than “suspendProcessing”, as “suspendRetrieval” leaves documents on the broker, while “suspendProcessing” queues them within the Integration Server (and stops dispatching threads to handle these documents).

One question - are you setting “persistChange”?

We are still hanging on to 6.1. I know 6.5 has really cool trigger features. We have wait for a while to make that happen!!

We are using both Processing as well as Retrieval valves. I would disagree to your statement that the documents leaves on the broker Vs IS. I think the documents remain on the broker minus the length of the trigger queue. Since the length of the trigger queue is between Retrieval and Processing valves. It would lose data on IS restart/history time to live. I agree, It would make sense to suspend Retrieval than processing, so you would NOT lose data thats on the trigger length.

The “persistChange” parameter is default – False. What does this do ?

Regarding your issue with my statement on the two types of “suspensions” for triggers, I will admit that the 6.1 documentation on this functionality (found in webMethods_Integration_Server_and_webMethods_Developer_Documentation_Supplement_Version_6.1_SP2.pdf) leaves much to be desired. This functionality doesn’t change for 6.5, and the 6.5 documentation is much more clear and concise. I reviewed both sets of documentation prior to responding to your post. I believe that you will find my statements are simply echos of documentated behavior.

If you set “persistChange” to “true”, changes to the trigger processing state(s) will persist after restart. If set to “false”, restarting IS will revert trigger processing to previously “persisted” states. If I were you, I would call your suspend services with “persistChange” set to “true” and see if this behavior continues.

Good luck, and write back with what you discover!

– Christopher Kovacs

Don’t understand why the triggers start processing again after 24 hours - never left them suspended for that long, though…

You won’t lose broker documents regardless of which suspension method you choose. The broker document does not get acked until the trigger service that is handling the document completes (either successfully or not). So, if you suspend processing and the IS goes down, the document will get picked up again. It is true that documents are queued on the IS as well, but they are not removed from the broker until service completion.

That being said, I agree with you both that suspend retrieval would be better in any case.

The trigger management feature of 6.5 was back-ported to 6.1 in SP2. So if you want that functionality - you can install SP2. Of course, that does not help if the triggers “unsuspend” themselves after 24 hours.

You also mentioned that you were disabling the triggers via developer - I hope you are running in a cluster, becuase if not, you can lose your broker subscriptions when you disable the trigger and any documents coming in will be discarded by the broker…

I tested this in non-Clustered environment and here are my findings…

• The Persist mode=true makes sure trigger status is stateful. It hold good in cases of IS restart, trigger package reload and trigger parameter changes. (which is contrary to FALSE mode). [which I am pretty happy about. Thanks for dctoph]. Testing in clustered Q enviornment, hopefully this works here as well.

• Reply to the comments from jlammers –

  • Why shouldn’t we leave trigger suspended for long ? Any reasons ?
  • You are correct, we would NOT loose broker documents, as long they are guaranteed and NOT volatile. I was talking about document in trigger queue. We would loose those, if Processing is suspended before retrieval and some documents gets trapped in the trigger queue and we have an IS restart.
  • We were disabling trigger in Developer on both Clusters and documents does get piled at the broker and not rejected (we have a wierd Broker Server configuration, which works good for this cause). May not work, for everybody out there.

No reason not to suspend for a long time - I’ve just never had occassion to do so…

Right, but the document in the trigger queue still exists on the broker until the service that is invoked by the trigger completes execution, so I’m not sure I understand what you mean by “trapped in the trigger queue” or how you could lose the document - should not happen.

That’s expected in a cluster - I was just warning that if you are not in a cluster, then disabling of a trigger via developer will end up in the subscriptions being removed from the Broker and the documents won’t pile up on the broker. Not sure why webMethods implements it this way - I always configure even stand-alone systems as “single-node clusters” to avoid this poor default behaviour.

Thanks for posting your test results…

Just curious, did setting persistence help with the issue you originally posted where “these trigger valves automatically opens up” [after about 24 hours]?

There are times. We have something called “Cutover tasks”, in which the business wants us to pile up the documents in queue and NOT send it to the target systems. Depending of type of cutover, we either clear the queue or resume the trigger valve.

I would disagree. The trigger queue is say length=2, is outside the broker (surprisingly, Broker Admin tool counts this too). This length is between retrieval trigger valve and processing trigger valve. So, say 10 documents are published when both valves are suspended. You resume retrieval valve and 2 documents flows through the trigger length (broker admin still shows 10). You suspend retrieval valve and resume processing valve. The Broker admin would now say 8 (2 documents reached target). This trigger queue (2 trapped documents), if NOT set up as guaranteed would lose documents on IS restart.

That’s correct. Thats why changing trigger valves status is efficient than changing trigger status. Also, changing trigger valves is a configuration change Versus changing trigger in Developer which is a code change. This is how I view it. Big deal, in cases where security is tight for PRD.

I am in middle of the achieving Niravana…LOL!

• Works great in case of NO-Broker reshuffle and both IS restart
• In case of Broker reshuffle, and both IS restart - the trigger valve status on the new broker IS fails to persists (the NON-Broker IS worked). We had some issues, in our repo database during this tests, so I will discard this test. Will do more tests tomorrow.

Sorry - you are, of course, correct for volatile documents since they are immediately removed from the broker.:o