On Fri, Jun 13, 2008 at 10:32 AM, Scott Lawrence <[EMAIL PROTECTED]> wrote: > > 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.
Incidentally, you can run multiple sip stacks in a single process. It should be fairly simple to tie together all the jain sip applications into a single jvm. However, we should architect that a bit. It is possible that some lightweight container architecture (even one that we craft up) with well defined xml rpc interfaces for service management would work. I would want to stay clear of things like J-SLEE. A light weight framework is what is called for. > > -- > 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/ > > -- M. Ranganathan _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
