On Thu, Aug 26, 2010 at 8:30 AM, Josh M. Patten <[email protected]>wrote:
> Even at 50 users the current RLS implementation has problems when > changing/adding any user attribute. This encompasses everything from setting > a call forward to changing an email address to adding a new user. Each time > one of these actions occurs the RLS server completely tears down the active > RLS list in memory and reloads it from scratch (very inefficient, very > not-scalable). While this is happening the RLS server "pauses" any new BLF > events which can cause the park monitors to appear locked because the signal > to terminate the BLF ringing is never sent. > > Hoa, one of our programmers here at Brazos County, recently took on the > challenge of rewriting the offending code in order to make it more efficient > and scalable and I think he's done it. I am running the RLS fix he wrote on > our production system (currently at 270 registered endpoints) and have yet > to see any of the behaviors that the old RLS implementation exhibited. I can > now make changes, add users, change user settings, etc. without locking up > the RLS server (with the current implementation once I got to about 200 or > so users the RLS server would lock up every time I made a change or added a > user). I have this fix available as a 64 bit RPM for 4.2.x. If anyone is > desperate for it I can email it to you. The patch will be put in the tracker > shortly. > > - > Thanks Josh. What build is your is your production system? It would be worth trying the your patch. Users at this site use web-ui and chat extensively so this might explain the increased park issues. Ping me off list and I'll test it I'll my lab first.
_______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
