I haven't seen it for a while, but we did have multiple copies of logs where this was happening a year or so ago. If (as another poster said) it's a bug that has been fixed, perhaps that's why I haven't seen it for a while.
From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Rick Westbrock Sent: Wednesday, August 20, 2014 10:47 AM To: arslist@ARSLIST.ORG Subject: Re: Wrong escalation execution time ** I thought undeclared escalations went into pool 1 by default as well. That being said I would agree that if you are going to the trouble to create separate pools it would be worth the effort IMO to analyze all your escalations and parse them out into separate pools based on scheduled execution time and expected run time to prevent bottlenecks. I have done that myself but only for custom escalations, not any of the ITSM workflow. -Rick From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing Sent: Wednesday, August 20, 2014 8:22 AM To: arslist@ARSLIST.ORG Subject: Re: Wrong escalation execution time ** 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 <wrentf...@stratacominc.com<mailto:wrentf...@stratacominc.com>> 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:arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>] On Behalf Of Brian Goralczyk Sent: Tuesday, August 19, 2014 6:39 PM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> 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 <d...@blairing.com<mailto:d...@blairing.com>> 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 <mahmoud.mahdy-moha...@vodafone.com<mailto: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<tel:%2B20%280%291004999638> Mail: mahmoud.mahdy-moha...@vodafone.com<mailto:mohamed.abdel-haf...@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<http://www.vodafone.com.eg/> ************************************************************************************************************************* _ARSlist: "Where the Answers Are" and have been for 20 years_ Doug -- Doug Blair d...@blairing.com<mailto:d...@blairing.com> +1 224-558-5462<tel:%2B1%20224-558-5462> 1208 East Fremont Street Arlington Heights, Illinois 60004 [cid:image001.png@01CFBC68.B6AFA9E0] 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<http://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_ _ARSlist: "Where the Answers Are" and have been for 20 years_ ________________________________ No virus found in this message. Checked by AVG - www.avg.com<http://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"
