I'm not sure I accurately understood the problem, but it sounds like this is a failure to use non-blocking I/O on the client?
Raimund Sacherer wrote: > oh boy, > > On Aug 25, 2009, at 10:05 PM, Alex Balashov wrote: > >> I've never seen that, myself. But I have no trouble believing it. >> >> That problem - along with Asterisk's other scalability quirks - must >> be >> properly managed. More boxes to spread the calls onto and >> underutilising the hardware on each node is a better extreme to tend >> toward than the opposite. > > I can tell you, it can and will bring down your machine if not used > *VERY*, *VERY* carefully! > > I have not once in my life (and i've done a lot of stuff) seen such a > dangerous beast as the AMI, if it's an API for a developer, who > develops stuff which are intended to be used by implementors, that's > fine, they know what they are doing. But the AMI is dangerous like an > API, but intended to be used by implementors which not necessarly do > have enough background! > > I had to rewrite a Click2Call solution to specifically use Locks to > prevent the following situation: > > the callcenter queried from a host of webservers our webserver, which > talks via AMI to get the free/occupied info on callagents > if a customer want to be called this was routed as well through the AMI. > > The problem is that at Times asterisk locks for some seconds the ami > interface, at times it is when a call setup takes longer, at times it > has nothing to do with call setups at all, it just locked the AMI and > the local apache processes which tried to get answers from the AMI > kept piling up, so at times the Lock got freed and everything went > normal again, but at times the lock took longer, Apache used up all > its possible threads (20 worker-servers a 254 connections) and > asterisk just locked up completely (100% cpu) load of the machine > about 80 or more. > > At times the machine was so completely hosed that you could not even > do anything on the local console so you had to cold-reset the machine! > > I now have implemented: > * a caching system for occupied requests > * a Lock system so I am sure only ONE thread systemwide can speak at > a given time with the AMI > * changed the call setup from AMI to pbx_spool > > In my oppinion a system integrator should not have to mess around with > locks and doing all this debugging and checking, if i have a manager > interface it should happily accept whatever i through at it, and do > internel locking, checking, discarding on problem totally safe on its > own! > > so, just be aware of WHAT you are doing with the AMI! > > best > Ray > > > _______________________________________________ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > AstriCon 2009 - October 13 - 15 Phoenix, Arizona > Register Now: http://www.astricon.net > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 _______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2009 - October 13 - 15 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
