<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 26.06.2019 17:48, Ben Newlin wrote:<br>
</div>
<blockquote type="cite"
cite="mid:F35CF714-ED43-4DB8-90D5-11C2017CF0B6@genesys.com">
<p class="MsoNormal">Thanks again for the info. I think what you
are saying is that the async operation is not launching a new
process to handle the called function, but is performing the
function in the original worker thread and only taking advantage
of any suspend/resume or polling functionality already exposed
by the underlying function itself.
<o:p></o:p></p>
</blockquote>
<tt>Just to clear this up: the underlying functions themselves need
not offer any polling functionality,<br>
they just need to meet two criteria: (1) be non-blocking; (2)
provide a valid fd for the async engine to poll on.<br>
</tt>
<p class="MsoNormal"><tt>Any blocking I/O functionality, be it
within libcurl, MySQL, etc. that meets the above can be adapted
to<br>
work with the async engine available in OpenSIPS 2.1+.</tt><o:p></o:p><o:p><br>
</o:p></p>
<blockquote type="cite"
cite="mid:F35CF714-ED43-4DB8-90D5-11C2017CF0B6@genesys.com">
<p class="MsoNormal">I understand that the practicalities of the
implementation in OpenSIPS may have required this design, but I
must re-iterate that these limitations need to be documented
very carefully as they are very important to understand when
designing OpenSIPS scripts with async functionality and are not
described anywhere. I could not find anywhere in the
documentation that indicates that async operations can
potentially still block the original worker thread and block
call processing. The closest is:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">“The current OpenSIPS worker will launch the
asynchronous operation, after which it will continue to process
other pending tasks”<o:p></o:p>
</p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">But this provides no elaboration on what it
means for the worker to “launch” the operation, and more
importantly it does not indicate that the launching itself can
block, which is the key issue here.<o:p></o:p></p>
</blockquote>
<tt>Agreed - will try to find a way to integrate this corner-case
into the docs, somehow.</tt><br>
<blockquote type="cite"
cite="mid:F35CF714-ED43-4DB8-90D5-11C2017CF0B6@genesys.com">
<p class="MsoNormal">As I said, this unfortunately makes async
processing mostly useless for us. For both DB and REST queries
if only the data transfer is async then it is only useful when
the data being transferred is extremely large or prone to
delays/jitter. Such transfers should be avoided during realtime
processing whether async or not, as they will still delay the
individual call even if not others. For small payloads, like the
single JSON object common in REST responses, it is the
connection itself that is the concern. Once connected, running
the data transfer in async mode represents no real gain.<o:p></o:p></p>
</blockquote>
<tt>Then I recommend you stop using rest_client, which currently
optimizes system resource<br>
usage for</tt><tt> setups where the TCP connect cannot possibly
ever hang, and resort to forking<br>
a process for each</tt><tt> HTTP request, using a construct such
as:</tt><br>
<p><tt> async(exec("curl your_connect_hanging_http_endpoint"),
resume_route);</tt><br>
</p>
<p><tt>Although forking a process for each request is a costly
operation which will<br>
eat more system resources during normal operation, at least this
solution optimizes<br>
for the worst case, when the HTTP server is down. In this
latter case, the<br>
throughput of your SIP server won't be hindered that much, as
the hanging connect<br>
will be done asynchronously.</tt></p>
<p><tt>Best regards,</tt><br>
</p>
<pre class="moz-signature" cols="72">Liviu Chircu
OpenSIPS Developer
<a class="moz-txt-link-freetext" href="http://www.opensips-solutions.com">http://www.opensips-solutions.com</a></pre>
</body>
</html>