[kamailio/kamailio] Feature request: http_async_query response route to resume execution from memory (#1642)
13 Sep
2018
13 Sep
'18
7:18 p.m.
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 or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1642
13 Sep
13 Sep
7:50 p.m.
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(a)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(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
17 Sep
17 Sep
9:54 a.m.
Closed #1642.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1642#event-1848929976
9:54 a.m.
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.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1642#issuecomment-421907460
2262
days inactive
2266
days old
3 comments
3 participants
participants (3)
-
alexsosic -
Daniel-Constantin Mierla
-
Federico Cabiddu