Please? Josh Patten Assistant Network Administrator Brazos County IT Dept. (979) 361-4676
On 7/13/2010 11:12 AM, Josh Patten wrote: > 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/ > _______________________________________________ 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/
