[asterisk-dev] [Code Review] 4399: HTTP: Stop accepting requests on final system shutdown.

[rmudgett]

> On Feb. 4, 2015, 2:17 p.m., Mark Michelson wrote:
> > "While a shutdown request is pending it is desirable to continue to process ARI HTTP requests for current calls"
> > 
> > I'm curious what the justification behind this is. I would expect that for a "now" or "graceful" shutdown, you would want similar behavior as for calls. That is, you'd want to stop accepting HTTP requests in order to allow for the shutdown to continue. For the "when convenient" shutdown, then I'd expect to continue taking HTTP requests until the final shutdown, like you've done here.

Existing calls in a gracefull shutdown should be able to continue in an IVR by sending DTMF digits and having a stasis application play recordings back or the application could send the call to voicemail with a prompt that representatives are not available.  Transfers obviously won't work because new channels cannot be created at this time but otherwise things should still function until the call hangs up.


- rmudgett


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


On Feb. 3, 2015, 2:10 p.m., rmudgett wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4399/
> -----------------------------------------------------------
> 
> (Updated Feb. 3, 2015, 2:10 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-24752
>     https://issues.asterisk.org/jira/browse/ASTERISK-24752
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> There are three CLI commands to stop and restart Asterisk each.
> 
> 1) core stop/restart now - Hangup all calls and stop or restart Asterisk.
> 
> 2) core stop/restart gracefully - Stop or restart Asterisk when there are
> no calls in the system.  New channels are prevented while the shutdown
> request is pending.
> 
> 3) core stop/restart when convenient - Stop or restart Asterisk when there
> are no calls in the system.  New calls are not prevented while the
> shutdown request is pending.
> 
> ARI has made stopping/restarting Asterisk more problematic.  While a
> shutdown request is pending it is desirable to continue to process ARI
> HTTP requests for current calls.  To handle the current calls while a
> shutdown request is pending, a new committed to shutdown phase is needed
> so ARI applications can deal with the calls until the system is fully
> committed to shutdown.
> 
> * Added a new shutdown committed phase so ARI applications can deal with
> calls until the final committed to shutdown phase is reached.
> 
> * Made refuse new HTTP requests when the system has reached the final
> system shutdown phase.
> 
> * Split the bridging framework shutdown to not cleanup the global bridging
> containers when shutting down in a hurry.  This is similar to how other
> modules prevent crashes on rapid system shutdown.
> 
> * Moved prototypes for ast_begin_shutdown(), ast_cancel_shutdown(), and
> ast_shutting_down() to asterisk.h.  You should not have to include
> channel.h just to access these system functions.
> 
> 
> Diffs
> -----
> 
>   /branches/13/main/http.c 431537 
>   /branches/13/main/bridge.c 431537 
>   /branches/13/main/asterisk.c 431537 
>   /branches/13/include/asterisk/channel.h 431537 
>   /branches/13/include/asterisk.h 431537 
> 
> Diff: https://reviewboard.asterisk.org/r/4399/diff/
> 
> 
> Testing
> -------
> 
> Extended the final shutdown phase sleep so I could send a HTTP request
> while in the final shutdown phase.  The HTTP request was not refused while
> the shutdown request was pending and refused after the final shutdown
> phase was reached.
> 
> 
> Thanks,
> 
> rmudgett
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20150205/e54844b9/attachment.html>