I would like this to be merged into the CURL module (it's mentioned in the todo). Having multiple modules calling CURL is not a good thing, especially if they use HTTPS (multiple initialisations of OpenSSL is not a good thing). That's also why Hugh added an API to the curl module, so we can build upon one single CURL binding. --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/480#issuecomment-172549865

Thanks for this module - a very useful feature! I have a couple of use cases for curl/async_http which are possibly off topic (major enhancements), I mention them here so that if any redesign/code sharing happens they are taken into account. * Sending asynchronous queries without suspending main transaction - e.g. for sending logging/notifications where result is not important - would run an event_route on response so stats etc. can be updated * Streaming multiple requests to the same destination - Avoid TLS handshake overhead for every request --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/480#issuecomment-173263621

Thanks Hugh for the feedback! On Wed, Jan 20, 2016 at 5:34 PM, Hugh Waite <notifications(a)github.com> wrote: current architecture, I'll have a look and try to have it implemented in the first release. currently :) I'll put in the module's TODO list. Again, thanks for the feedback. --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/480#issuecomment-173476074

If both modules should be used at the same time, the most problematic point would be calling `curl_global_init()` several times IMO (although the libcurl documentation states that it must be called "at least" once). However, **async_http** uses the `curl_global_init_mem()` version (it allows curl to use kamailio's memory API instead of the libc one), and if it is called after `curl_global_init()`, it will have no effect. We chose to bind libcurl with the SHM memory API, because the amount of memory needed to handle the HTTP requests and responses under heavy load can be huge, and it made more sense to increase the shared memory pool size than the private ones. The drawback is the cost of the SHM locking for each operation. Another option could be to allocate a new dedicated memory pool to each HTTP worker (or a shared one amongst the workers), this is now easily doable with the new kamailio memory API. So, in a nutshell, to use both modules at the same time, libcurl initialization should be done in a shared API that would ensure that the initialization is done only once per process. To do this, we also have to agree on the memory API used by libcurl. In your opinion(s), what is the best alternative: libc's malloc, SHM, PKG, dedicated (private / shared) pool? --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/480#issuecomment-173998873

It is using system memory by default indeed, but we preferred kamailio's pools, to have a better view/control on what is going on. --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/480#issuecomment-174001794

Some commits following received suggestions: - allow global and per query cert and key configuration - memory manager configuration - allow to send a query without suspending the transaction --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/480#issuecomment-176125305

Merged #480. --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/480#event-537615394