[asterisk-dev] AMI connection handling

[Dan Jenkins, HolidayExtras.com]

On 19 September 2013 09:10, Olle E. Johansson <oej at edvina.net> wrote:

>
> 19 sep 2013 kl. 10:07 skrev jg <webaccounts at jgoettgens.de>:
>
> > Under which circumstances does this happen, except that it happens
> randomly? Is it related to your commands or with a flood of events? Which
> CSTA library are you using?
> >
> > I am currently writing a TAPI service provider and for test purposes I
> have several connections up all the time. I have never seen that
> connections suddenly die.
>
> If you have a lot of actions you want to open one connection for reading
> events and one or multiple for sending actions as they are mostly
> synchronous. The TCP read queue grows otherwise and at some point you will
> have trouble in your app since you can't send.
>
> I don't know how that affects the TCP connection state, guess that depends
> on the implementation.
>
> /O
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>



I've had this issue before, where we have a lot of actions being sent and
received - on a busy phone system

I changed over to do exactly what Olle is talking about, one for writing
and I eventually ended up with 3 for reading and each one of those had a
different user which had allowed events set against each one so that I
didn't receive the event 3 times.

This solved any stability/slowness issues I had, the TCP connections just
couldn't deal with sending all of the traffic I was asking of them.
Remember, that if you don't setup allowed events against the AMI user, you
will be receiving all of the events that Asterisk sends on each AMI
connection - so you can use the "eventfilter" parameter against the user in
manager.conf to restrict particular events - to a higher degree than the
read and write parameters.

On a related note, we were having issues a while back in Elastix/Freepbx in
that we were pressing reload and it would never reload, what was happening
was that the TCP connection was being opened and being flooded, and then
the script would timeout before it got a chance to send the reload command.

I've diverged but hopefully this gives you a bit of background and a
possible solution.

Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130919/d3401a98/attachment.htm>