On Tue, 2009-02-03 at 07:25 -0500, Damian Krzeminski wrote: > Nikolay Kondratyev wrote: > > Just imho: > > > > Won’t it be better to keep “activate” button in the UI? > > > > Because there is hi possibility that “auto-activation” will lead to > > numerous proxy/registrar restarts instead of just one…. > > > > I think, that auto activation of dialplan creates conditions for > > significant non necessary downtime… > > > > Again: this is just imho from the administrator perspective… > > > > Thanks and regards, > > > > Nikolay. > > > > Both proxy and registrar restart quickly and their restart does not affect > calls that are already in progress. It would be better if they did not > require restart after dial plan changes.
In principle, dial plan changes should not be too hard to make reloadable, and we now have most of the infrastructure in place that we would need to do so (sipXsupervisor knows when they are replicated, so it could signal the process in some way to reload the files). Not something for 4.0, but a good candidate for 4.2. > We really cannot live with manual activation for much longer. There are > just too many places that affect dial plan and I have seen on this list > many reports of problems that originated from dial plan not being activated. I think a simple warning on the screen that you have uncommitted changes would help that quite a lot. > The activation strategy has a "quite time" interval that can be tweaked - > by default it waits 15 seconds of quiet time (no dial plan related changes) > before activating it. > > Let's give it a try: if it causes problems we can get it back to "on > demand" strategy. I share Nikolay's concern... restart is not completely harmless... on a busy system (especially one without HA) it could be disruptive. At the very least, I suspect that 'quiet time' should be much longer (at least a minute), and there should be a display on the page of what state it is in. Incidentally... on an HA system, does sipXconfig restart services on both systems at the same time? It would be less disruptive to restart services on each host on a rolling schedule so that redundant services won't be restarting at the same time. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
