On Aug 29, 2024, at 6:35 PM, Ben Kaufman bkaufman@bcmone.com wrote:
So, using kamailio's ASYNC module, the pattern would be to call async_task_route() in listener process A. This passes the transaction to async_worker process A. Then, in the async_worker process, the http request is made and that async worker process is blocked until the web server responds. And yes, if that's what is happening it is just moving the wait time from one process to another.
With the http async client, however, my understanding is that the request is sent from listener process A, and then the transaction is suspened. The http async worker process, which not the same as async workers, is running an event loop (libevent is a requirement for http async client). When a http reply is received, the http async worker will resume the transaction that sent the request.
The difference is that with the http async client, waiting for the http reply doesn't block anything. Supposing we have a single listener process and a single http async worker process. In very quick succession, 5 SIP requests are received, all requiring an http request. If the 5th http request is the first to receive an http response, then that response will be handled immediately - it's not blocked waiting for the prior 4 http replies.
I understand your argument, as I did before. There is a nonblocking socket event mux, in a dedicated process outside of the normal process pools, which is running an event loop on behalf of those normal processes and activating async workers with a resumed transaction when an HTTP reply is received. While that waiting is happening, the async workers are not themselves blocked.
However, in this setup, the async workers only do one kind of thing -- postprocess the HTTP response. That's all they do. So, there's nothing they're freed up to do by not waiting on HTTP queries, and, conversely, there's nothing to be gained from adding more of them in this paradigm that wouldn't also be gained by adding more of them and having them each do a blocking HTTP query, as in the first paradigm you discussed above.
This whole polemic is rooted in the fact that issuing redirects based on HTTP responses is all that this proxy does. If it did anything else, these would all be fair points.
-- Alex