I believe that there's a conflation of the http_async_client module and the async module going on here. My understanding (and testing bears out), that the http async client module works in the manner you describe as being "mediated by external events" in that the http reply is the external trigger that resumes the transaction. It appears that the module abstracts any actual calls to suspend/resume.
I created a test project that demonstrates this: https://github.com/whosgonna/kamailio_http_async Using the container deminy/delayed-http-response<https://registry.hub.docker.com/r/deminy/delayed-http-response> to create an http service that sleeps 1 second and then replies, and having Kamailio set with 2 child listening processes, and 1 http_async_client worker, a simple use of the http_async_query() function handles 300 cps sustained over a minute with no problems. This passes all of the latency load onto the http server. Yes, if the http server cannot handle the request load as the requests increase, that will be a problem, but I think the understanding of how this module works is incorrect. Kaufman Senior Voice Engineer E: [email protected] SIP.US Client Support: 800.566.9810 | SIPTRUNK Client Support: 800.250.6510 | Flowroute Client Support: 855.356.9768 [img]<https://www.sip.us/> [img]<https://www.siptrunk.com/> [img]<https://www.flowroute.com/> ________________________________ From: Alex Balashov via sr-users <[email protected]> Sent: Tuesday, August 27, 2024 6:57 AM To: Kamailio (SER) - Users Mailing List <[email protected]> Cc: Alex Balashov <[email protected]> Subject: [SR-Users] Re: http_async and tm CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. > On Aug 27, 2024, at 4:17 AM, Henning Westerholt via sr-users > <[email protected]> wrote: > > The asynchronous HTTP client only helps you if you are having other traffic > that can be handled without the need for HTTP API calls, and/or if you are > having traffic fluctuations, so you can prevent blocking by buffering > requests in memory basically. Indeed. It's also worth reiterating that the meaning of "asynchronous" is somewhat environmentally and implementationally specific. As the term has entered general use with the popularity of single-threaded / single event loop multiplexing systems, such as Node and JavaScript, it has come to refer to a programming and processing pattern in which the waiting and detection of I/O is delegated to the OS kernel network stack. The OS takes care of this juggling and calls event hooks or callbacks in your program when there is I/O to consume, or sets some flag or condition to indicate this so that you can read the I/O from some OS buffer at your convenience. In this way, your program is able to proceed executing other kinds of things while the OS is taking care of waiting on I/O. Provided that the workload consists of waiting on I/O and also other things, this is to the general benefit of "other things", not the I/O. In Kamailio, asynchronous processing just means liberating the transaction from the main worker processes, which are part of a relatively small fixed-size pool, by suspending it and shipping it to another set of ancillary worker processes, also part of a relatively small, fixed-size pool. Within those ancillary worker processes, the execution is as linear, synchronous and blocking as it would be in the main worker processes. This does not cause the processing to enter some generally more asynchronous mode in any other respect, and in that sense, is quite different to what most people have in mind when they think of asynchronous processing in the context of general-purpose programming runtimes. The only real footnote to this is about situations in which the resumption of the transaction in the async workers is mediated by external events, e.g. a POST-back into Kamailio's `xhttp` server. While this does not change the nature of the subsequent synchronous execution of the route logic, it does mean that neither a core CIP worker nor an async worker is tied up while some kind of external processing is playing out. -- Alex -- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fevaristesys.com%2F&data=05%7C02%7Cbkaufman%40bcmone.com%7C870a790256344872731208dcc68ffcab%7Cafc1818e7b6848568913201b9396c4fc%7C1%7C0%7C638603568952398508%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Baqrm4TWB8dZrVKaeh87CcswweXIzP7OPdTN%2BJRpH9k%3D&reserved=0<https://evaristesys.com/> Tel: +1-706-510-6800 __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to [email protected] Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
__________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to [email protected] Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
