On Tue, 2008-09-09 at 00:19 -0400, Damian Krzeminski wrote: > Kevin Thorley wrote: > > On Mon, 2008-09-08 at 20:46 +0000, Scott Lawrence wrote: > > [...] > >> Other than a general objection to polling, I guess not. What frequency > >> were you thinking of using? > >> > > > > I have a general objection to polling as well, but this seems to be the > > easiest way to squeeze this in to sipXconfig during this sprint. Damian > > had mentioned a 30 second polling interval. I think we could safely go > > up to 2 minutes and still maintain a reasonable amount of "liveness" in > > the system. We could also make this a configurable param (either > > through sipXconfig or a config file) if it were to cause problems in > > certain network environments. > > > > Kevin > > > > > > sipXconfig is only going to poll when admin adds a new server which is not > configured yet, right? > It's not going to poll all the servers, all the time (at least not for that > reason). > > And if that's the case we can get down to about 10 seconds: the goal is to > get the new server noticed and configure it as soon as it starts. > > How about the Raymond's question though: how does sipXconfig is going to > contact supervisor for the first time? > > Looks like the initial exchange was to be done through HTTP PUT of the > gzipped file. See: > > http://track.sipfoundry.org/secure/attachment/15317/ClusterManagement.html#config.if > > Which would suggest that the polling could be implemented as HTTP GET on > the same URL. Bad idea?
We need to review the initial setup scenarios in more detail, but this is _not_ just to support that. Suppose that any configuration change is made, and the push of that change to the distributed system fails because that system is down? When the distributed system comes back, the checkin provides the stimulus to tell sipXconfig that it can now successfully send the update. On the other hand, that doesn't help if the problem was a network problem but both systems were up, so I guess you have to poll for that one anyway. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
