> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Krzeminski, Damian (BL60:9D30) > Sent: Monday, September 29, 2008 2:47 PM > To: [EMAIL PROTECTED] > Subject: Re: [sipX-dev] process management restructure question > > 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: > > <snip> > > > > 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? > There is no guarantee that any process will start, if some of its dependencies are not met. The "old" ProcMgmtRpc code waited for 15 seconds (for one process) or 45 seconds (for a list of processes), but the sipXconfig xmlrpc code which sends the request only waits for 5 seconds. All of this waiting for something which might not come seems pointless to me. I think the ProcMgmtRpc code should just acknowledge the request, and sipXconfig can then query the actual status (which might be Starting, or indicate ResourceRequired etc).
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
