Http async queries work using the Kamailio tm framework, used by all the modules exposing async behaviour. A change in this behaviour, which implies a rework of the whole framework, is not something that can be done easily and for sure not for a single module.

On Thu, 13 Sep 2018, 18:18 alexsosic, notifications@github.com wrote:

From the official kamailio documentation of the function http_async_query(url, route_name)

Sends HTTP(S) request asynchronously to the URL given in “url” parameter, which is a string that may contain pseudo variables.

Parameter “route_name” defines the route to be executed upon reception of HTTP reply, on error or on timeout. If a transaction exists before calling http_async_query(), it will be paused and resumed in this route, while the routing script execution will be stopped. If executed in a transactionless context, or if $http_req(suspend) is used not to suspend the transaction, the routing script execution will continue and the query result will be available in “route_name”.

Because the routing script execution will be stopped it's quite difficult for some advanced usages to restore the previous variables and logic and to continue with the execution.

The problem of resuming the work is delegated to the user and not Kamailio itself. I think Kamailio should freeze the execution and store all needed data in memory to resume execution after the http response like for a normal http sync query.

So the stopping will become pausing/resuming.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/kamailio/kamailio/issues/1642, or mute the thread https://github.com/notifications/unsubscribe-auth/AF36ZUwTx3srFXBXxJFOuZr_ietKx8mlks5uaoVNgaJpZM4Wnp61 . _______________________________________________ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Use avp, xavp or hash table variables, they store the values in shared memory. Moreover, avp/xavp are associated with the suspended transaction and available after continue as they were at suspend time.

Execution jumps to a route block, so whatever you want to have in the same route block after suspend, move to a dedicated route block. Of course, returning in the execution stack done before suspend doesn't work.

But this is something that is specific to parallel processing, the reason for share memory to exist as a concept. Same is also with multi-threading, no share memory because threads work all with same private memory, but there are variables on the stack as well as thread context. You can find many libc functions that have the `thread safe` version, so they require a stack variable or a context.

Even in other programming languages, all async functions require a callback to be provided, which is executed when async task is completed, and as part of globals (shared memory), the rest of variables before async exec are not available.

In short, this is what technology does right now (at least in C), if I am mistaken and someone has solutions, I will be happy to hear and learn.

I am closing this one, if you want to discuss more about this topic, or how to leverage avp/xavp/htable to pass info from suspend time to continue time, should be done on sr-users mailing list.