William, I have never seen that, I have experienced that any escalation that doesn't have a pool defined runs in pool 1 (legacy style)....do you have a workable example of a non-pooled escalation jumping to a pool other than 1?
On Wed, Aug 20, 2014 at 8:46 AM, William Rentfrow < [email protected]> wrote: > ** > > There's one other thing that can be really vexing when dealing with this > problem. > > > > Let's decide you go multi-threaded. You put your escalation that needs to > run every minute on a new pool (thread) of #4. You set some of the others > to 1, 2, and 3. > > > > But...if you leave ANY of the escalations undeclared for which pool they > should use, they still CAN use #4, and mess up your escalation. I've seen > that happen quite a few times. > > > > So basically - if you are going to define a pool for one escalation - you > might as well do it for ALL of the escalations. > > > > *From:* Action Request System discussion list(ARSList) [mailto: > [email protected]] *On Behalf Of *Brian Goralczyk > *Sent:* Tuesday, August 19, 2014 6:39 PM > *To:* [email protected] > *Subject:* Re: Wrong escalation execution time > > > > ** > > One of the tricks that I have found to help is to look at the number of > records that are in the table and how many are returned by your escalation. > Then decide what is being done to them and does it need to be single > threaded? If not, and you just need the escalation to schedule the work it > might be something that you can turn multi-threaded in the way it runs by > having an escalation for that has one record and performs a push to all the > matching records. > > > > I can go into this deeper if anyone prefers. But it can definitely > improve the performance of escalations. > > > > Brian Goralczyk > > > > On Tue, Aug 19, 2014 at 1:15 PM, Doug Blair <[email protected]> wrote: > > ** > > 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 < > [email protected]> 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:* *[email protected] > <[email protected]>* > > > > > ************************************************************************************************************************* > > 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 > > [email protected] > > +1 224-558-5462 > > > > 1208 East Fremont Street > > Arlington Heights, Illinois 60004 > > > > > > ITILv3 > > > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > > > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > ------------------------------ > > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2014.0.4745 / Virus Database: 4007/8066 - Release Date: 08/19/14 > _ARSlist: "Where the Answers Are" and have been for 20 years_ > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
