----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4399/#review14439 -----------------------------------------------------------
Ship it! Ship It! - Mark Michelson On Feb. 5, 2015, 9:58 p.m., rmudgett wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/4399/ > ----------------------------------------------------------- > > (Updated Feb. 5, 2015, 9:58 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. > New channels are prevented while the shutdown request is pending. > > 2) core stop/restart gracefully - Stop or restart Asterisk when there are > no calls remaining 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. Starting anything while the system is actively > releasing resources and unloading modules is not a good thing. > > * 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 ast_begin_shutdown(), ast_cancel_shutdown(), and > ast_shutting_down(). You should not have to include channel.h just to > access these system functions. > > > Diffs > ----- > > /branches/13/res/res_pjsip_pubsub.c 431574 > /branches/13/res/res_pjsip/pjsip_options.c 431574 > /branches/13/main/http.c 431574 > /branches/13/main/channel.c 431574 > /branches/13/main/bridge.c 431574 > /branches/13/main/asterisk.c 431574 > /branches/13/include/asterisk/channel.h 431574 > /branches/13/include/asterisk.h 431574 > /branches/13/channels/chan_sip.c 431574 > /branches/13/apps/app_confbridge.c 431574 > > 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 > >
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
