[asterisk-users] Asterisk Autodialer

[Alex Balashov]

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