Carolyn Beeton wrote: >> -----Original Message----- >> From: Lawrence, Scott (BL60:9D30) >> Sent: Monday, September 15, 2008 1:49 PM >> To: Beeton, Carolyn (CAR:9D60) >> Cc: [EMAIL PROTECTED] >> Subject: Re: [sipX-dev] process management restructure question >> >> >> On Mon, 2008-09-15 at 11:08 -0400, Carolyn Beeton wrote: >>> Is the existing RPC defined in ProcMgmtRpc still intended >> to function >>> as currently implemented, but sending requests on the the new >>> sipXsupervisor/SipxProcess? (this would be >> setUserRequestState[All] >>> where state is one of USER_PROCESS_STOP, USER_PROCESS_START, or >>> USER_PROCESS_RESTART) >>> >> My assumption so far has been that we would try to minimize >> what sipXconfig needs to change to be compatible with the new >> sipXsupervisor process management, and translate the "old" >> rpc commands into the new process state model events >> internally. I had not gotten far enough to be sure this >> would not cause problems, though. >> >> The old process model was that sipXconfig (or some other >> xml-rpc caller, in theory) issued stop/start/restart >> commands. The new one is really that start and stop become >> changes to the desired state, and restart becomes, in effect, >> "stop this now but don't change the desired state, so it will >> start again right away". Whether or not we should change the >> xml-rpc interface may be worth discussing, but my feeling has >> been that we could probably avoid it. >> >> The one important differenc that I think we will want to >> expose is that the new supervisor process model has a lot of >> information about _why_ a process is not starting, and that >> should be made available to sipXconfig somehow so that it can >> either act on it or display it for the admin. >> >> >> > > The existing rpc has a "blockForStateChange" parameter. Am I correct to > assume that this goes away, replaced by each process's knowledge of its > dependencies, based on the process definition? (It's a bad idea for > xml-rpc stuff to block anyway, as the underlying connections time > out...) >
I am not clear how the "blockForStateChange" is related to dependencies between the processes. I was under impression that this is a way of making synchronous vs. asynchronous calls. If I remember correctly this is the only way sipXconfig is using this API at the moment (all those calls are issued as blocking calls). Why is it a bad idea that RPC call is blocking? What exactly times-out? If something does time out isn't it an indication of failure anyway? > Another question: how do the processes get "enabled" in the first place? > They are currently coming up "disabled". Are we expecting sipXconfig to > send a start command (xmlrpc) for each process on system start up > (reflecting the HA distribution of services)? > > Carolyn _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
