[asterisk-dev] [Code Review] 4325: PJSIP: Prevent slow graceful shutdown when outbound publications have not started
Mark Michelson
reviewboard at asterisk.org
Wed Jan 14 14:27:22 CST 2015
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4325/
-----------------------------------------------------------
(Updated Jan. 14, 2015, 2:27 p.m.)
Status
------
This change has been marked as submitted.
Review request for Asterisk Developers and Kevin Harwell.
Changes
-------
Committed in revision 430608
Bugs: ASTERISK-24655
https://issues.asterisk.org/jira/browse/ASTERISK-24655
Repository: Asterisk
Description
-------
If an outbound publish is configured, and that publication never published any data, then a graceful shutdown would result in Asterisk hanging for a while before finally shutting down.
The reason is that the code did not take into account the case where we never started publishing anything. The code would attempt to send a PUBLISH to stop publication, relying on the PUBLISH callback to be called so we could then destroy the PJSIP publishc structure, destroy our publication client, and signal to the unloading code that we were done. The problem is that the PUBLISH callback was never being called, presumably since pjsip_publishc_send() was failing.
I modified the code to outright destroy the PJSIP publishc structure and drop its reference to our publication client if we never actually started publishing anything. This way, shutting down gracefully doesn't wait for a callback that will never occur.
Also, feel free to give a better suggestion for a function name than "kill_it". There are already so many variations on destroying clients in that file, I was a bit bankrupt for ideas.
Diffs
-----
/branches/13/res/res_pjsip_outbound_publish.c 430354
Diff: https://reviewboard.asterisk.org/r/4325/diff/
Testing
-------
Reproduced the issue originally as described in ASTERISK-24655. With the patch here, I have confirmed that the issue no longer occurs.
I won't be writing a testsuite test for this, since the testsuite is not really well suited to this sort of thing.
Thanks,
Mark Michelson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20150114/f9978072/attachment.html>
More information about the asterisk-dev
mailing list