FYI: http://track.sipfoundry.org/browse/XX-8474 check the diagram and the bottom comment.
My coworker (the developer) has a beta of this fix written and we are testing it now in our EDE environment. Everything is working so far but we want to test every aspect of it to make sure it is stable before a patch is posted. Here is why this needed to be fixed: The way RLS is currently implemented every time a change is made to certain attributes of users or a user is added or removed the RLS service dumps the entire list of subscriptions for all ~~rl~ lists and sets up new subscriptions for each ~~rl~ list. This is just all around bad for large installations with over 200 subscriptions (like me) as it causes a huge flood of resubscriptions which ends up locking up the RLS server causing BLFs to be inoperable. An ideal fix for this scenario is to only refresh all the subscriptions for whatever individual ~~rl~ list got changed however due to the potential size of the ~~rl~F~~~id~xmpprlsclient list, which is the list that monitors all IM enabled extensions for the IM status updates, this simply wasn't enough for very large organizations. One further step was taken: only refresh subscriptions within each individual ~~rl~ list that have changed, leaving all current valid subscriptions intact. If anyone has suggestions or comments based on the diagram let us know. On 06/11/2010 01:03 AM, Tony Graziano wrote: > I recall this happens and I have to restart park service, but it takes > 10-20 minutes to "settle" and become useable. > > On Thu, Jun 10, 2010 at 11:32 PM, Josh Patten<jpat...@co.brazos.tx.us> wrote: > >> Now it happens every time I modify a BLF........ >> >> I'm in trouble..... >> >> Josh Patten >> Assistant Network Administrator >> Brazos County IT Dept. >> (979) 361-4676 >> >> >> On 6/10/2010 10:00 PM, Josh Patten wrote: >> >>> http://track.sipfoundry.org/browse/XX-8474 >>> >>> I just experienced this in a big way when modifying speed dials for 3 >>> attendant consoles with 25 monitored extensions on each. The Presence >>> service stopped responding after I updated them both and I had to >>> restart the Presence service for BLF to start working again. >>> >>> Please consider voting for this issue if you haven't. The dev team has >>> already stated they know how to fix this, but the demand has to be there >>> for it to happen. >>> >>> Even in relatively small installation this could happen. >>> >>> Josh Patten >>> Assistant Network Administrator >>> Brazos County IT Dept. >>> (979) 361-4676 >>> >>> >>> On 5/27/2010 9:03 AM, Josh Patten wrote: >>> >>> >>>> http://track.sipfoundry.org/browse/XX-8474 >>>> >>>> Everyone, if you plan on building a large installation of sipX any time >>>> in the future go vote for that issue. >>>> >>>> Josh Patten >>>> Assistant Network Administrator >>>> Brazos County IT Dept. >>>> (979) 361-4676 >>>> >>>> >>>> On 5/27/2010 8:02 AM, WORLEY, Dale R (Dale) wrote: >>>> >>>> >>>> >>>>> ________________________________________ >>>>> From: sipx-users-boun...@list.sipfoundry.org >>>>> [sipx-users-boun...@list.sipfoundry.org] On Behalf Of Josh Patten >>>>> [jpat...@co.brazos.tx.us] >>>>> >>>>> I don't know if this question has been answered before, but what is the >>>>> maximum number of extensions that can monitor, via BLF (sipXrls) a >>>>> single user extension or park extension? >>>>> >>>>> Will 75 phones monitoring the same 4 park extensions cause things to go >>>>> haywire or be unreliable? >>>>> _______________________________________________ >>>>> >>>>> In principle, any number of phones can monitor any extension. The >>>>> "Resource List Server" maintains one subscription to the extension, and >>>>> each monitoring phone maintains one subscription to the RLS. The RLS >>>>> takes care of redistributing the status information. This is a nice >>>>> architecture because it avoids overloading the phones; many phones can't >>>>> handle an unlimited number of subscriptions. >>>>> >>>>> The problem is that the RLS is a bit fragile when it comes to setting up >>>>> subscriptions. Currently, when any change is made to the set of "who >>>>> monitors whom", the RLS sets up all its subscriptions again. This >>>>> results in a huge flurry of messages that can overflow some internal >>>>> message queues, and can cause the RLS to lock up. Note that this problem >>>>> happens only when the BLF assignments are changed; once the RLS reloads >>>>> the BLF definitions correctly, it can handle ongoing traffic just fine. >>>>> >>>>> As a rule of thumb, I'd say that if you have less than 200 "who monitors >>>>> whom" specifications ("speed dial" entries with "monitor presence" >>>>> checked), you're on safe ground. Above that and I expect there is a risk >>>>> of lockup each time you change the BLF assignments. >>>>> >>>>> If you think this is a problem, please file an improvement issue (and get >>>>> others to vote for it). We know how to alleviate this problem, but there >>>>> isn't enough demand yet for us to have put in the work on it. >>>>> >>>>> Dale >>>>> >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> sipx-users mailing list sipx-users@list.sipfoundry.org >>>> List Archive: http://list.sipfoundry.org/archive/sipx-users >>>> Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users >>>> sipXecs IP PBX -- http://www.sipfoundry.org/ >>>> >>>> >>>> >>> _______________________________________________ >>> sipx-users mailing list sipx-users@list.sipfoundry.org >>> List Archive: http://list.sipfoundry.org/archive/sipx-users >>> Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users >>> sipXecs IP PBX -- http://www.sipfoundry.org/ >>> >>> >> _______________________________________________ >> sipx-users mailing list sipx-users@list.sipfoundry.org >> List Archive: http://list.sipfoundry.org/archive/sipx-users >> Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users >> sipXecs IP PBX -- http://www.sipfoundry.org/ >> >> > > > _______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users sipXecs IP PBX -- http://www.sipfoundry.org/
