> On April 5, 2014, 3:02 a.m., Olle E Johansson wrote: > > I would like to see a configuration option for this, as it will generate a > > massive amount of events in busy servers. > > Mark Michelson wrote: > That's fair. I can think of two ways to do this: > > 1) The DeviceStateChange and PublishStateChange belong to a new event > category. This way, you can add the event category to your read= line in > manager.conf if you want to see the event, or you can leave the category off > if you don't. > 2) There can be individual configuration options in manager.conf to > suppress certain events. This would act as a generic method to disable the > publication of certain events and could be applied to any event. > > Personally, I like number 2 more, but I'm willing to hear suggestions for > other ways of doing this. > > Mark Michelson wrote: > Interestingly, I wasn't aware of this until I dived into the manager > code, but you can already set up individual events to be filtered out if you > want. If you put > > eventfilter = !DeviceStateChange > eventfilter = !PresenceStateChange > > Then these events will be suppressed. This has been around since 1.8
eventfilters are for preventing excessive TCP traffic, or hiding certain events for security reasons. They actually add CPU overhead. Each eventfilter runs regexec() from within an ao2_t_callback_data for every event. I am also concerned about the impact of topic_forwarder generating full AMI packets before eventfilters are processed. As an alternative, isn't the point of stasis so we don't add stuff to the core unless it's universally useful? If this were res_manager_devicestate and res_manager_presencestate or similar, they could easily be set to noload. I have no doubt the information provided by these events will be useful to some, but not me. I'm not tied to the idea of this stuff living in modules, but would like to see a way to disable the topic_forwarder's. - Corey ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3417/#review11505 ----------------------------------------------------------- On April 10, 2014, 4:10 p.m., Mark Michelson wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/3417/ > ----------------------------------------------------------- > > (Updated April 10, 2014, 4:10 p.m.) > > > Review request for Asterisk Developers. > > > Repository: Asterisk > > > Description > ------- > > AMI does not emit events when device state or presence state changes. The > closest things that exist currently are the ExtenstionStatus and > PresenceStatus events, which inform about device state and presence state > events as they pertain to hints in the dialplan. These new events are raised > for every device state change or presence state change in Asterisk. > > > Diffs > ----- > > /trunk/main/presencestate.c 411714 > /trunk/main/manager.c 411714 > /trunk/main/devicestate.c 411714 > /trunk/include/asterisk/presencestate.h 411714 > /trunk/include/asterisk/devicestate.h 411714 > > Diff: https://reviewboard.asterisk.org/r/3417/diff/ > > > Testing > ------- > > See /r/3418 > > > Thanks, > > Mark Michelson > >
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
