Scott Lawrence wrote: > 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 ... >
The problem is that sipXconfig currently reprocesses registrations and removes duplicates. Unless it's somehow done on a server it needs to retrieve all registrations. Granted it could do it in batches. Improving XML/RPC IMDB methods performance would not hurt of course. REST actually lends itself quite well for queries that would be needed to retrieve or update a subset of IMDB records. Additional benefit would be language independent access to IMDB. Changing the protocol of course does not automatically solve the registrations issue. D. _______________________________________________ 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/
