On Thu, 2009-09-24 at 16:20 -0400, Dale Worley wrote: > On Thu, 2009-09-24 at 16:07 -0400, Raymond Dans wrote: > > In the main stream, however, I'd like some thoughts on a better/more > > generic way of speculating on the size of the response that's going to > > be built so that we can reduce/eliminate the UtlString resizing. Please > > note that this would still not be the ideal solution. The underlying > > problem of using XML-RPC in these scenarios will still exist and a "new" > > approach will eventually be required. > > All of what you say is good. But we may be able to attack the problem > by observing that sipXconfig isn't going to display all 10,000 > registrations at once. So maybe it's possible to define an XML-RPC that > selects a subset of the registrations (e.g., "starting with seq. no. N, > continuing for M entries"). That would ipso facto have a small return > value.
Similarly, the problem with registry replication is just with the initial sync - there's no reason when that could not be a series of calls that each have some reasonable maximum number of entries. Some careful thought needs to be done about not having failures delay startup too long, but the current strategy of doing the initial resync as just one call clearly won't scale... we knew that when we built it, but ... _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
