Lalit- I think that having the set/clear scripts immediately exec a new process is the better of the two options. It gets you around the single-threaded nature of the Notifier, which you¹ve seen limits how quickly you can process alarms. It also gets you around a related issue we¹ve found, which is that if something goes wrong and the set or clear script never exits, the Notifier will sit and wait forever. In effect, it stops processing alarms.
Another option would be to have the set/clear scripts write files to a particular directory one file per invocation. Then you have a daemon watch the directory, and process and delete the files. This offers a couple of advantages. First, files sitting in the directory for some time can indicate a problem. Also, unlike with the Notifier where you only get one chance to process a particular alarm, if there are any issues with a particular alarm¹s file, the daemon can simply retry the problem file again as long as it¹s sitting in the directory. HTH, Jim -- JIM PFLEGER | Application Architect | Insight | insight.com t. 480.889.9680 f. 480.889.9599 [email protected] On 7/22/11 1:29 PM, "Lalit Tyagi" <[email protected]> wrote: > List, > > I would like to have your suggestion or best practice to handle setscript and > clearscript. We have a big setscript and clearscipt which took almost 5-8 > seconds to execute all commands. > > If we clear 100s of alarms or put lots of devices into maintenance mode (which > in turn generates maintenance alarm) then our scripts backed up as it is > taking 5-8 sec to process all alarms sequentially (8 x 100 = 800 sec) . > > I have couple of following option but I would like to know other best possible > solution: > > 1. Have multiple SANM policy which handed over alarm to separate > alarmnotifer processes (Different alarmnotifer to handle Maintenance\Minor & > CRITICAL\MAJOR alarms) > > 2. Spawn a new independent process from setscript or clearscript and > perform all actions from there instead of sectscrip\clearscript. (All alarms > could be handle almost at the same time) > > > > Thanks > --Lalit Tyagi > > ---------------------------------------- > > This message is intended exclusively for the individual(s) or entity to > which it is addressed. It may contain information that is proprietary, > privileged or confidential or otherwise legally exempt from disclosure. > If you are not the named addressee, you are not authorized to read, > print, retain, copy or disseminate this message or any part of it. > If you have received this message in error, please notify the sender > immediately by e-mail and delete all copies of the message. > * --To unsubscribe from spectrum, send email to [email protected] with the > body: unsubscribe spectrum [email protected] > --- To unsubscribe from spectrum, send email to [email protected] with the body: unsubscribe spectrum [email protected]
