[OpenSIPS-Users] Rest Client Async operation

[Ben Newlin]

Liviu,

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.

This is very different from the way I had hoped async would work. The documentation does not speak to the specific implementation of async, so it was all assumptions on my part. But to me when you say async it means a separate process or thread is being created to perform the function. This would allow that process to block on the connect or any other aspect of the called function as necessary without blocking call processing, which is the desired outcome of any async operation.

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:

“The current OpenSIPS worker will launch the asynchronous operation, after which it will continue to process other pending tasks”

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.

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.

As far as investigating why the server is not responding, of course we will always do this. But we cannot anticipate or fix every cause of remote system failure. In order to design a resilient system we cannot assume the remote server will always be there. We had believed async would allow call processing to proceed in failure cases like this without blocking.

Ben Newlin

From: Users <users-bounces at lists.opensips.org> on behalf of Liviu Chircu <liviu at opensips.org>
Reply-To: OpenSIPS users mailling list <users at lists.opensips.org>
Date: Wednesday, June 26, 2019 at 9:23 AM
To: "users at lists.opensips.org" <users at lists.opensips.org>
Subject: Re: [OpenSIPS-Users] Rest Client Async operation


It's the same process doing both the connect and the transfer.  The problem is that libcurl, as it stands now,
is not able to give me a file descriptor to poll on, until it connects [1].  See this section:

"When libcurl returns -1 in max_fd, it is because libcurl currently does something that isn't possible
for your application to monitor with a socket and unfortunately you can then not know exactly when the
current action is completed using select(). You then need to wait a while before you proceed and call
curl_multi_perform anyway. How long to wait? Unless curl_multi_timeout gives you a lower number, we
suggest 100 milliseconds or so, but you may want to test it out in your own particular conditions to
find a suitable value."

Regarding your issue: I would investigate further the reason why the connect is hanging, and not getting
rejected immediately when your server is down.  That would solve all your blocking issues.

The same with MySQL connections which go down: only after the connection is up are we able to obtain
its file descriptor to asynchronously poll on.  So if connect to DB_HOST:3306 hangs, so will OpenSIPS.

Regards,

[1]: https://curl.haxx.se/libcurl/c/curl_multi_fdset.html<https://curl.haxx.se/libcurl/c/curl_multi_fdset.html>

Liviu Chircu

OpenSIPS Developer

http://www.opensips-solutions.com<http://www.opensips-solutions.com>
On 25.06.2019 18:41, Ben Newlin wrote:
but I guess my question would be why isn’t the entire operation run in async? Why must the connect be performed in the current process and only the transfer be in another process?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20190626/abbcda98/attachment-0001.html>