> 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/
