Mahmoud, I have done quite a bit of fiddling with just this situation.
Simply put, out-of-the-box the Escalation process is single threaded, which means that with no further adjustments only one escalation can operate at any given time. A long running escalation will delay the start of others, and a very long running escalation can cause some cases of the shorter ones to be skipped entirely. To fix this you can add threads to the escalation process (390603). This will allow more than one escalation to run at the same time. This will allow more of your escalations to complete without blocking each other, but still might allow some to be delayed. There is also the chance that some escalations depend on other escalations to be completed before they will do what is expected. The notification engine has a couple cases like this. These sorts of escalations can be grouped together using escalation pools. Please do not be tempted to add one thread or pool for every escalation! That would work, but would waste a lot of resources and potentially slow things down. You will need to turn on escalation logging and see how many escalations are ready too fire each minute, then adjust the number of threads so that more of them will fire and complete. Then group the ones which should not be blocked into unique pools. You can experiment with all of these pools and threads a bit, and remember that each thread, whether in an escalation queue or any other queue will tax the system somewhat. You want those threads to be mostly busy, and for there to be at least one thread/pool combination to be available every minute for your essential one. One way to be certain this happens might be to isolate your critical escalation in a pool by itself (let’s say pool 3), set your escalation threads to 3, and set all the other escalations to either pool NULL (which is the default) or pools 1-2. Anything in pool 1 or 2 will run on one of the first two available threads, and your essential one will be the only thing that runs in thread 3. You might have several escalations which need to fire every minute. As long as those don’t take a long time to run they could be all in the same pool. If you find that running all the escalations assigned to pool 3 takes longer than a minute, you’ll need to look at more threads or more pools. You can also investigate scheduling of the escalations. It is very common to find that a lot are scheduled to run at :00 in each hour (the default value). Perhaps some of these can be mored to another time so they do not all trigger at once. All that said, there is also the possibility that some of your escalations might be poorly written and just be doing things very inefficiently. Look closely at the RUNIF qualifications of those that seem to take a long time to complete, and turn those just as you would an inefficient filter qualification or search for a report or other lookup… Hope this helps! Doug Blair On Aug 19, 2014, at 4:04 AM, Mahmoud Mahdy-Mohamed, Vodafone Egypt <mahmoud.mahdy-moha...@vodafone.com> wrote: > ** > Dears, > Kindly help as I’m facing a critical issue, the escalations are running > randomly regardless the execution time that it should execute in. For example > I have escalation that has to run every minute however it is running after 30 > min which causes a delay in other related work flows. > Note:- I’m using 7.6.04 SP4 > > Thanks, > Best Regards, > > Mahmoud Mahdy Mohammed,PMP | Business Process Automation > Technology | Products & Services Delivery > Phone: +20(0)1004999638 > Mail: mahmoud.mahdy-moha...@vodafone.com > > ************************************************************************************************************************* > > The content of this document is classified as Vodafone Egypt S.A.E. > Confidential and Proprietary Information. > > The recipient hereby is committed to hold in strict confidence the contents > of this (e-mail, document, information) and not to disclose to any third > party without the prior written consent of Vodafone Egypt S.A.E. Recipient > will be held liable for any unauthorized disclosure. > > If you have received this message in error, please notify the sender by > return e-mail and delete the message in its entirety, including any > attachments. > > http://www.vodafone.com.eg > > > ************************************************************************************************************************* > > _ARSlist: "Where the Answers Are" and have been for 20 years_ Doug -- Doug Blair d...@blairing.com +1 224-558-5462 1208 East Fremont Street Arlington Heights, Illinois 60004 ITILv3 _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
