[asterisk-dev] [Code Review] 2749: Simplify Asterisk stop sequence

[Matt Jordan]

> On Aug. 9, 2013, 8:25 p.m., David Lee wrote:
> > /asterisk/trunk/lib/python/asterisk/asterisk.py, line 351
> > <https://reviewboard.asterisk.org/r/2749/diff/2/?file=43863#file43863line351>
> >
> >     Why the callLater? You could just call __cancel_stops directly, right?

callLater with a time of 0 will schedule the callback with Twisted to run as "soon as possible". This lets any pending operations that were blocked finish and/or fire (even if they were callbacks on a separate chain of deferred calls).

Since we're doing this in a deferred callback, it's polite to let someone else have a turn if possible.


- Matt


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


On Aug. 8, 2013, 6:27 p.m., Matt Jordan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2749/
> -----------------------------------------------------------
> 
> (Updated Aug. 8, 2013, 6:27 p.m.)
> 
> 
> Review request for Asterisk Developers and David Lee.
> 
> 
> Repository: testsuite
> 
> 
> Description
> -------
> 
> The Asterisk stop sequence was a tad complex. It would:
>  * Perform a core stop gracefully with a total of 5 retries
>  * Perform a core stop now with a total of 5 retries
>  * Send a TERM
>  * Send a KILL
> 
> This actually was counterproductive for a few reasons:
> 1. Once Asterisk has initiated a shutdown sequence, it will refuse any subsequent shutdown attempts. Thus, once the first 'core stop gracefully' is received, any further 'core stop gracefully' attempts or 'core stop now' attempts will be rejected. Furthermore, a 'core stop gracefully' will return success - even if the process doesn't exist - as Asterisk will pretty much always accept an attempt to shutdown from the Test Suite. So the retries/core stop now sequence actually did nothing.
> 2. If we don't stop gracefully, for whatever reason, we either have to wait indefinitely or we have to kill the process. There isn't anything else to be done.
> 
> This patch does the following:
> 1. It sends a core stop gracefully. If that fails, a scheduled KILL will eventually terminate the process.
> 2. It adds some additional checks to verify if the process is actually still running before starting the shutdown sequence. This should more gracefully handle conditions when Asterisk crashes or otherwise prematurely exits.
> 3. It stops consuming errors in the DeferredList of stop deferred callbacks. If one of them throws an exception, we'll crash out. This helps prevent situations where an exception in a stop deferred callback causes the chain of deferreds to stop and hang the test.
> 
> 
> Diffs
> -----
> 
>   /asterisk/trunk/lib/python/asterisk/TestCase.py 4000 
>   /asterisk/trunk/lib/python/asterisk/asterisk.py 4000 
> 
> Diff: https://reviewboard.asterisk.org/r/2749/diff/
> 
> 
> Testing
> -------
> 
> A number of tests that hung the Test Suite now finish to conclusion (and their failure)
> 
> 
> Thanks,
> 
> Matt Jordan
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130809/9700e0e7/attachment-0001.htm>