[asterisk-dev] [Code Review] 2807: Add a reloadable option for sorcery type objects

[Mark Michelson]

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

Ship it!


Ship It!

- Mark Michelson


On Aug. 30, 2013, 5:16 p.m., Kevin Harwell wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2807/
> -----------------------------------------------------------
> 
> (Updated Aug. 30, 2013, 5:16 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-22382 and ASTERISK-22384
>     https://issues.asterisk.org/jira/browse/ASTERISK-22382
>     https://issues.asterisk.org/jira/browse/ASTERISK-22384
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> Some configuration objects currently won't place nice if reloaded.  Specifically, in this case the pjsip transport objects.  Now when registering an object in sorcery one may specify that the object is allowed to be reloaded or not.  If the object is set to not reload then upon reloading of the configuration the objects of that type will not be reloaded.  The initially loaded objects of that type however will remain.
> 
> While the transport objects will not longer be reloaded it is still possible for a user to configure an endpoint to an invalid transport.  A couple of log messages were added to help diagnose this problem if it occurs.
> 
> 
> Diffs
> -----
> 
>   branches/12/res/res_pjsip_outbound_registration.c 398018 
>   branches/12/res/res_pjsip/config_transport.c 398018 
>   branches/12/include/asterisk/sorcery.h 398018 
>   branches/12/main/sorcery.c 398018 
>   branches/12/res/res_pjsip.c 398018 
> 
> Diff: https://reviewboard.asterisk.org/r/2807/diff/
> 
> 
> Testing
> -------
> 
> Ran asterisk with a couple of pjsip endpoints configured for a valid transport.  Changed the transport name on the transport type and issued a 'core reload' and observed that the transport was not reloaded and calls could still be made.  Then changed the transport name on an endpoint to one that didn't exist and after reloading observed that calls failed, but an error message was logged stating that the transport could not be found.  Also verified the reported crash no longer occurred.
> 
> 
> Thanks,
> 
> Kevin Harwell
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130830/b13feff8/attachment.htm>