Dale, can we restart dialog on this? My coworker is wondering what we should do next: http://track.sipfoundry.org/browse/XX-8646
Josh Patten Assistant Network Administrator Brazos County IT Dept. (979) 361-4676 On 7/5/2010 1:51 PM, WORLEY, Dale R (Dale) wrote: >> From: Josh Patten [[email protected]] >> >> Upon working with the programmer that is writing the fix to >> http://track.sipfoundry.org/browse/XX-8474 (which is mostly done, but >> more testing to do) we thought of a situation where even this fix may >> prove inadequate: the RLS list used by the Openfire IM engine. As far >> as I know it encompasses every user that has IM enabled on the system. >> > Yes, and handling that one case correctly seems to be an important > scalability problem. > > >> Even with the XX-8474 fix if there was a move/add/change that caused >> ONLY the Openfire RLS list (~~rl~F~~~id~xmpprlsclient) to change, >> wouldn't every resource in the Openfire RLS list need resubscription >> even though subscriptions to this resource may already exist in other >> resource lists? >> > Strictly speaking, part of the intended change of XX-8474 is to not > require reconstruction of all the subscriptions for the xmpprlsclient > resource list when one URI is added/deleted from it. That is, that a > resource list can be altered without deleting and recreating it > entirely. > > >> While this may not be a big deal on smaller systems it could be >> potentially toxic for systems that have 200 or more IM users as each >> change would require resubscription to all endpoints. >> > While the current market target for sipXecs does not reach above 200 > users, I believe that the current code has this problem for even 200 > users. > > >> 1. Does every resource list for every user make a new, separate >> subscription to each registered endpoint/park queue? >> > No. As you could determine by reading the code. (Does your > programmer understand the current RLS implementation?) > > The RLS maintains a cache of "resource URIs". When a resource is > added to a resource list, a ResourceReference for the URI is added to > the ResourceList. The ResourceReference points to a ResourceCached > for that URI. While there may be many ResourceReferences for a single > URI, there is only one ResourceCached for it. The ResourceCached > creates the necessary subscriptions for monitoring the URI, and hence > those subscriptions are not duplicated if the URI appears in multiple > resource lists. > > (With the introduction of the "~~in~" users, it is possible that two > different resource URIs can create subscriptions to the same > destination URI, and we should have another cache to prevent that. > But that hasn't become a practical problem yet, so we haven't > addressed it.) > > >> Implementing this could possibly pave the way for a distributed RLS >> server that could run on multiple servers for reliability, >> redundancy, and load balancing. Imagine if you will splitting >> subscription load between two servers 50/50, exchanging information >> between the two servers by using XML-RPC or whatever would best suit >> this setup. >> > The load on servers is not significant, but redundancy would be > useful. Unfortunately, the obvious redundancy technique requires each > redundant RLS to maintain a subscription to every phone, doubling the > burden on the phones.. > > >> 2. Would it be possible for sipXrls to resubscribe only to parts of >> the individual resource list that have changed (not the whole thing >> which XX-8474 addresses, just the individual ~~rl~F~XXXX lists) >> instead of dumping the whole ~~rl~f ~XXXX list or is this technically >> impossible? >> > In principle, yes. But the code needs to be written. Also, it cannot > be done without extending the current ResourceList::addResource, as it > cannot add a resource to a resource list in a specific location, and > the order of resources in a list is significant. > > Dale > _______________________________________________ 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/
