-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3811/#review13082
-----------------------------------------------------------


My time is 100% consumed by a project for now, I will resubmit when I have time 
to work on this.

- Corey Farrell


On Aug. 1, 2014, 6:22 p.m., Corey Farrell wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3811/
> -----------------------------------------------------------
> 
> (Updated Aug. 1, 2014, 6:22 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-24068
>     https://issues.asterisk.org/jira/browse/ASTERISK-24068
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> This change moves main/manager_*.c to loadable modules, allowing those events 
> to be disabled by not loading the modules.  This can be accomplished by 
> eventfilter, but eventfilter has a couple issues.  It actually adds more 
> overhead to asterisk since the outbound events must be parsed for each AMI 
> user.  Additionally it causes skips in SequenceNumber, preventing use of that 
> tag to determine if any events were missed during a reconnect.
> 
> Besides converting from built-in units to modules, changes are made to 
> VarSet, ChannelTalkingStart and ChannelTalkingStop.  They no longer use 
> .to_ami callbacks, but instead subscribe to the stasis events like the rest 
> of the res_manager_channels events.  A couple functions were also moved from 
> manager_bridging.c and manager_channels.c to manager.c since they are still 
> needed even if these modules are noload'ed.
> 
> AST_MODULE_INFO_STANDARD for all modules will be updated once r3802 is 
> committed.  This or r3812 will need to be updated depending on which is 
> committed first.
> 
> 
> Diffs
> -----
> 
>   /trunk/res/res_manager_system.c PRE-CREATION 
>   /trunk/res/res_manager_mwi.c PRE-CREATION 
>   /trunk/res/res_manager_endpoints.c PRE-CREATION 
>   /trunk/res/res_manager_channels.c PRE-CREATION 
>   /trunk/res/res_manager_bridges.c PRE-CREATION 
>   /trunk/main/stasis_channels.c 419804 
>   /trunk/main/stasis_bridges.c 419804 
>   /trunk/main/manager_system.c 419804 
>   /trunk/main/manager_mwi.c 419804 
>   /trunk/main/manager_endpoints.c 419804 
>   /trunk/main/manager_channels.c 419804 
>   /trunk/main/manager_bridges.c 419804 
>   /trunk/main/manager.c 419804 
>   /trunk/main/logger.c 419804 
>   /trunk/main/channel.c 419804 
>   /trunk/include/asterisk/manager.h 419804 
>   /trunk/build_tools/get_documentation 419804 
> 
> Diff: https://reviewboard.asterisk.org/r/3811/diff/
> 
> 
> Testing
> -------
> 
> Ran some testsuite's to verify some of the events were still being sent to 
> AMI:
> tests/manager/originate
> tests/apps/channel_redirect
> tests/bridge/connected_line_update
> tests/feature_call_pickup
> tests/apps/dial/dial_answer
> tests/apps/chanspy/chanspy_barge
> tests/funcs/func_push
> 
> This did not provide complete coverage for all effected events, but does 
> verify many events from res_manager_channels.c.  Events from other files were 
> not tested, though res_manager_channels.c was the most likely to cause 
> problems.
> 
> 
> Thanks,
> 
> Corey Farrell
> 
>

-- 
_____________________________________________________________________
-- 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

Reply via email to