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

[Kevin Harwell]

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


Changes
-------

Addressed review findings.


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 (updated)
-----

  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/06312258/attachment.htm>