<br><br><div class="gmail_quote">On Wed, Aug 26, 2009 at 2:58 AM, Raimund Sacherer <span dir="ltr"><<a href="mailto:rs@runsolutions.com">rs@runsolutions.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
oh boy,<br>
<div class="im"><br>
On Aug 25, 2009, at 10:05 PM, Alex Balashov wrote:<br>
<br>
><br>
> I've never seen that, myself. But I have no trouble believing it.<br>
><br>
> That problem - along with Asterisk's other scalability quirks - must<br>
> be<br>
> properly managed. More boxes to spread the calls onto and<br>
> underutilising the hardware on each node is a better extreme to tend<br>
> toward than the opposite.<br>
<br>
</div>I can tell you, it can and will bring down your machine if not used<br>
*VERY*, *VERY* carefully!<br>
<br>
I have not once in my life (and i've done a lot of stuff) seen such a<br>
dangerous beast as the AMI, if it's an API for a developer, who<br>
develops stuff which are intended to be used by implementors, that's<br>
fine, they know what they are doing. But the AMI is dangerous like an<br>
API, but intended to be used by implementors which not necessarly do<br>
have enough background!<br>
<br>
I had to rewrite a Click2Call solution to specifically use Locks to<br>
prevent the following situation:<br>
<br>
the callcenter queried from a host of webservers our webserver, which<br>
talks via AMI to get the free/occupied info on callagents<br>
if a customer want to be called this was routed as well through the AMI.<br>
<br>
The problem is that at Times asterisk locks for some seconds the ami<br>
interface, at times it is when a call setup takes longer, at times it<br>
has nothing to do with call setups at all, it just locked the AMI and<br>
the local apache processes which tried to get answers from the AMI<br>
kept piling up, so at times the Lock got freed and everything went<br>
normal again, but at times the lock took longer, Apache used up all<br>
its possible threads (20 worker-servers a 254 connections) and<br>
asterisk just locked up completely (100% cpu) load of the machine<br>
about 80 or more.<br>
<br>
At times the machine was so completely hosed that you could not even<br>
do anything on the local console so you had to cold-reset the machine!<br>
<br>
I now have implemented:<br>
* a caching system for occupied requests<br>
* a Lock system so I am sure only ONE thread systemwide can speak at<br>
a given time with the AMI<br>
* changed the call setup from AMI to pbx_spool<br>
<br>
In my oppinion a system integrator should not have to mess around with<br>
locks and doing all this debugging and checking, if i have a manager<br>
interface it should happily accept whatever i through at it, and do<br>
internel locking, checking, discarding on problem totally safe on its<br>
own!<br>
<br>
so, just be aware of WHAT you are doing with the AMI!<br>
<br>
best<br>
Ray<br>
<div><div></div><div class="h5"></div></div></blockquote><div><br>Ray,<br><br>Thanks for explaining what I was saying in technical/mechanical terms. <br><br>My quote, "The AMI has been notorious for bogging down and halting systems when used in an intensive way." didn't mean much without the behind the scenes explanation of the hows and whys.<br>
<br>I just chalked it up to being buggy. <br><br>One of the last things you want to do as the guy who handles the system is do a full reboot when Asterisk becomes completely unresponsive, you have hundreds of agents sitting idle and even more customers calling in.<br>
<br>Fun times at the next meeting with management! Monetize your downtime and the AMI can be very expensive.<br></div></div><br>-- <br>Thanks,<br>Steve Totaro <br>+12409381212 (Cell)<br>+12024369784 (Skype)<br>