<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">El 19/09/2013 3:41 a. m., Dan Jenkins,
HolidayExtras.com escribió:<br>
</div>
<blockquote
cite="mid:CACgt05iuUQW+_kVwbHk0=z4ky62k9JnHkqk5Ziov0UGGB_5wvw@mail.gmail.com"
type="cite">
<div dir="ltr">On 19 September 2013 09:10, Olle E. Johansson <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:oej@edvina.net" target="_blank">oej@edvina.net</a>></span>
wrote:<br>
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
19 sep 2013 kl. 10:07 skrev jg <<a
moz-do-not-send="true"
href="mailto:webaccounts@jgoettgens.de">webaccounts@jgoettgens.de</a>>:<br>
<div class="im"><br>
> 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?<br>
><br>
> 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.<br>
<br>
</div>
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.<br>
<br>
I don't know how that affects the TCP connection state,
guess that depends on the implementation.<br>
<span class=""><font color="#888888"><br>
/O</font></span><br>
</blockquote>
</div>
</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">I've had this issue before, where we
have a lot of actions being sent and received - on a busy
phone system</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">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.</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">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.</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">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.</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">I've diverged but hopefully this gives
you a bit of background and a possible solution.</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">Dan</div>
<br>
</div>
</blockquote>
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.<br>
<br>
Best Regards,<br>
Miguel Molina<br>
</body>
</html>