[asterisk-dev] AMI connection handling

[Miguel Molina]

El 19/09/2013 3:41 a. m., Dan Jenkins, HolidayExtras.com escribió:
> On 19 September 2013 09:10, Olle E. Johansson <oej at edvina.net 
> <mailto:oej at edvina.net>> wrote:
>
>
>     19 sep 2013 kl. 10:07 skrev jg <webaccounts at jgoettgens.de
>     <mailto: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
>
>
>
> 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
>
Thank you very much for the insights, we're going to separate the 
writing from the reading in separate AMI sockets, to see if the 
stability improves. Olle is right, the response to an action is blocking 
and synchronous, while the events are asynchronous.

Best Regards,
Miguel Molina

-----------------------------------------------------------------------------------
Este mensaje y sus anexos son para uso exclusivo de sus destinatarios y puede
contener informacion confidencial y/o privada protegida legalmente. Si usted 
no es el destinatario, se le notifica que cualquier distribucion o reproduccion
de este mensaje, o de cualquiera de sus anexos, esta estrictamente prohibida. 
Si usted ha recibido este mensaje por error, por favor notifiquenos inmediatamente
y elimine su texto original, incluidos los anexos y destruya cualquier reproduccion
del mismo. Las opiniones expresadas en este mensaje son responsabilidad exclusiva
de quien las emite y no necesariamente reflejan la posicion de Millenium Phone 
Center S.A, ni comprometen la responsabilidad institucional por el uso que el 
destinatario haga de las mismas. 
-----------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130919/05d355c9/attachment-0001.htm>