I believe the limit is based on hardware capacity
On Fri, Sep 6, 2013 at 11:34 AM, Pruitt, Christopher (Bank of America Account) <christopher.pru...@hp.com> wrote: > ** > > I have a question regarding this topic. Is there a limit on the number of > Escalation Pools you can have on a server? We currently run with 4 but I > was wondering if we can increase that to a number higher than that and if > so what it the maximum number allowed?**** > > ** ** > > *Christopher Pruitt* > Business Consulting III**** > > Remedy Developer**** > > *HP Enterprises Services* > *christopher.pru...@hp.com* > www.hp.com **** > > [image: HP_logo]**** > > ** ** > > ** ** > > *Confidentiality Notice:* This message and any files transmitted with it > are intended for the sole use of the entity or individual to whom it is > addressed, and may contain information that is confidential, privileged, > and exempt from disclosure under applicable law. If you are not the > intended addressee for this e-mail, you are hereby notified that any > copying, distribution, or dissemination of this e-mail is strictly > prohibited. If you have received this e-mail in error, please immediately > destroy, erase, or discard this message. Please notify the sender > immediately by return e-mail if you have received this e-mail by mistake.* > *** > > ** ** > > *From:* Action Request System discussion list(ARSList) [mailto: > arslist@ARSLIST.ORG] *On Behalf Of *Thad Esser > *Sent:* Friday, September 06, 2013 11:19 AM > > *To:* arslist@ARSLIST.ORG > *Subject:* Re: How many escalation pools do you have...?**** > > ** ** > > ** **** > > My first thought was the same as Fred's - do you have enough queues > defined, so I can't offer much more in that regard. However, you mention > that you are restarting the server to clear up the dead thread. Back in > the 6.3 days, there was a version (patch 21 I think), where you could end > up with ghost threads for escalations. The fix was to disable escalations > on the server settings, which would kill all the escalation threads, and > then re-enable the setting, which starts them back up. Changing this > setting doesn't require a restart of the AR server. So while your issue is > slightly different, maybe doing that will clear your dead thread without > having to restart the whole server.**** > > ** ** > > Thad**** > > ** ** > > On Thu, Sep 5, 2013 at 5:35 PM, William Rentfrow < > wrentf...@stratacominc.com> wrote:**** > > ** **** > > I can see it in the logs. All of the escalations that have no pool > defined will run in a random thread.**** > > **** > > For example, our 4th thread was defined for a custom notification-type > escalation. It is the only thing that is assigned to pool 4 - but in the > logs I see other threads accessing that pool - especially during those > times when the escalation defined for pool 4 has died.**** > > **** > > B.**** > > **** > > *From:* Action Request System discussion list(ARSList) [mailto: > arslist@ARSLIST.ORG] *On Behalf Of *Grooms, Frederick W > *Sent:* Thursday, September 05, 2013 5:27 PM > *To:* arslist@ARSLIST.ORG > *Subject:* Re: How many escalation pools do you have...?**** > > **** > > ** **** > > We currently have 3 pools on a pure custom (NON ITSM) system.**** > > **** > > Where did you hear that pools are shared? According to the docs the only > time an escalation specified to run in a pool (thread) will run in a > different pool is if you don’t define enough thread queues for the number > of pools you are using. (i.e. You tell an escalation to run in pool 4 but > you only have 2 escalation queues defined. The escalations set for pools 3 > and 4 run in the first one instead). Escalations are delayed if another is > running in the pool.**** > > **** > > Straight from the docs **** > > Escalations can be assigned to pools so the escalations from each pool run > in parallel on separate threads within the escalation queue. To use > escalation pools, you must first configure multiple threads for the > escalation queue as described in the Configuration Guide, “Queues,” page > 27. If you assign an escalation to a pool that has no thread configured, > the escalation is run by the first thread.**** > > **** > > All escalations in a particular pool run on the same thread, so the > execution of escalations within a pool is serialized. Escalations run in > the order of their firing times, but an escalation is delayed if an > escalation from the same pool is currently running. If two or more > escalations have dependencies and must not run at the same time, put them > into the same pool to make sure they run in sequence.**** > > **** > > Fred**** > > **** > > **** > > *From:* Action Request System discussion list(ARSList) [mailto: > arslist@ARSLIST.ORG] *On Behalf Of *William Rentfrow > *Sent:* Thursday, September 05, 2013 5:06 PM > *To:* arslist@ARSLIST.ORG > *Subject:* How many escalation pools do you have...?**** > > **** > > ** **** > > Hi listers -**** > > **** > > So we have an infrequent but recurring problem. One of our > mission-critical escalations (interval, 5 minutes) will every once in a > while die. It will stop appearing in the escalation log, and the only way > to fix it is to bounce the admin server.**** > > **** > > There's 204 total escalations on this server, the vast majority of which > are ITSM 7.6.04 base product.**** > > **** > > We are entering 4000-5000 tickets a day, with additional data being > entered in CM, CMDB, etc., so the data load even for things like the > 5-minute recurring SLM Measurement escalation can be significant.**** > > **** > > We have configured the one that breaks it to run on a specific pool and no > others are configured to use that pool. Unfortunately that doesn't mean > that pool isn't shared - others can hop in that pool too if the others > pools are busy. (Kind of thinking of submitting an RFE for a "dedicated > pool" option that prevents sharing but that's another issue altogether).** > ** > > **** > > So - how many pools do you use? We currently have a max of 4 and obviously > that's not enough.**** > > **** > > William Rentfrow**** > > wrentf...@stratacominc.com**** > > Office: 715-204-3061**** > > Cell: 715-398-5056**** > > **** > ------------------------------ > > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2013.0.3392 / Virus Database: 3222/6639 - Release Date: 09/04/13* > *** > > _ARSlist: "Where the Answers Are" and have been for 20 years_ **** > > _ARSlist: "Where the Answers Are" and have been for 20 years_ **** > > ** ** > > _ARSlist: "Where the Answers Are" and have been for 20 years_ **** > _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"
