|
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. 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? 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. We need some clarification on a few things: 1. Does every resource list for every user make a new, separate subscription to each registered endpoint/park queue? If the answer is yes, then my next question is why? Why can't the RLS server make one subscription to each registered endpoint and then distribute the information to each individual resource list? It seems monumentally wasteful for resource lists that have the same subscriptions to create new connections to each endpoint for the exact same information. 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. 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? It seems like maintaining the active subscriptions and only resubscribing when absolutely necessary is much more efficient than the "dump and refill" method currently used. Perhaps I'm totally guano insane but I think these scalability issues need to be addressed if sipXecs is ever to be considered for large scale (IE replacing Nortel Option 61c and larger) deployments. |
_______________________________________________ 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/
