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

Matt Jordan reviewboard at asterisk.org
Fri Aug 30 11:28:14 CDT 2013


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



branches/12/main/sorcery.c
<https://reviewboard.asterisk.org/r/2807/#comment18753>

    I'm not sure why, because this is valid, but I always struggle with using a char as something other than a string of characters. Maybe it's the C++ programmer in me attempting to escape.
    
    Anyway, I'd change this to be an integer (signed or otherwise) bit field with length 1. Personally, I find it conveys the intent of the variable better than char.
    
    



branches/12/main/sorcery.c
<https://reviewboard.asterisk.org/r/2807/#comment18754>

    Same comment here. Take in an unsigned int.



branches/12/main/sorcery.c
<https://reviewboard.asterisk.org/r/2807/#comment18755>

    This shouldn't be a WARNING, as it isn't technically an error. A NOTICE message may be appropriate.


- Matt Jordan


On Aug. 29, 2013, 8:38 p.m., Kevin Harwell wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2807/
> -----------------------------------------------------------
> 
> (Updated Aug. 29, 2013, 8:38 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/include/asterisk/sorcery.h 397937 
>   branches/12/main/sorcery.c 397937 
>   branches/12/res/res_pjsip.c 397937 
>   branches/12/res/res_pjsip/config_transport.c 397937 
>   branches/12/res/res_pjsip_outbound_registration.c 397937 
> 
> 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/476572fb/attachment-0001.htm>


More information about the asterisk-dev mailing list