This never touches the SIP stack, it only deals with parsing of the resource list XML and changing values in the internal "database" of subscriptions.
On 07/01/2010 05:45 PM, Todd Hodgen wrote: > Was this new approached checked with compliance of the necessary standards. > That's my only thought. > > -----Original Message----- > From: sipx-users-boun...@list.sipfoundry.org > [mailto:sipx-users-boun...@list.sipfoundry.org] On Behalf Of Josh Patten > Sent: Thursday, July 01, 2010 3:40 PM > To: Tony Graziano > Cc: sipx-users@list.sipfoundry.org > Subject: Re: [sipx-users] Max amount of users monitoring park extension? > > 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/ > > _______________________________________________ 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/
