On Fri, 2008-06-13 at 09:30 -0400, Andy Spitzer wrote: > Woof! > > On Fri, 13 Jun 2008 08:27:40 -0400, Scott Lawrence <[EMAIL PROTECTED]> wrote: > > > Currently, the new process definition schema [1] requires that there be > > a 'stop' command element. We could make this element optional - if the > > element were not specified, then the sipXsupervisor would just kill the > > process specified by the pid file. If we make this change, I'd want to > > require the pid file (which is now optional in the schema, but I believe > > that we have one for every service). Opinions? > > Stop should be mandatory. It should be up to the service to determine how it > wants to be stopped, not sipXsupervisor. This moves us away from > sipXsupervisor > sending signals. That doesn't prevent the "stop" command from using signals, > but it opens the door to other means of stopping a service.
That is the current state of affairs. > PID files should be optional, because sooner rather than later we are going > to start combining disparate services into the same process (multiple JVMs > are wasteful--we really went down the wrong path there separating them) and > so there needs to be a way for sipXsupervisor to deal with that. Enforcing a > PID file per service would break this. Very good point. When we get there, we can extend the sipXecs-process schema to allow control mechanisms other than executing a command, if needed. -- Scott Lawrence tel:+1.781.229.0533;ext=162 or sip:[EMAIL PROTECTED] sipXecs project coordinator - SIPfoundry http://www.sipfoundry.org/sipXecs CTO, Voice Solutions - Bluesocket Inc. http://www.bluesocket.com/ http://www.pingtel.com/ _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
