Brett,
The timeout for the async ops will be control by the reactor (like
triggering the timouts) and set by the module starting the op - like the
rest_client module will set the timeout for the HTTP rest queries.
The processes are not suspended, just the context of an execution. So at
the end is just about memory - of course there should be a safety net to
limit the number of suspended async I/Os per type of I/O. Each type of
I/O op will have a priority in relation to other I/O ops (like timer
jobs higher than aysnc resume, async resume higher than reading from
network).
An async I/O is done during handling a SIP message, so it does not
interfere with TM timers (which are activated only when sending the
traffic out). otherwise the dialogs and transactions (with their
eco-system) are not affected at all.
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 02.09.2014 19:53, Brett Nemeroff wrote:
I'm curious what the failure cases look like here..
What happens when your "long running db query" is excessively long? Is
there a timeout? What happens if you have 1000s of backed up
processes. Would love to see some sort of fifo command somehow
quantify the effectiveness of it being async. Not sure how to say this
right. But I'd like to be able to query a value that says either "bg
tasks are being handled in a timely fashion" or "bg tasks are so slow
it's starting to affect performance"
Of course, these are not "normal" cases... wondering how "graceful" we
can allow it to be broken. I assume that the context saving will take
X memory and eventually it will fill up? Where is that memory stored?
How is it allocated? How much memory do you need for each backgrounded
task?
Another thought.. how are dialog/transaction "variables" handled?
AVPs? "vars"? How are dialogs handled across such an operation? What
about standard (SIP) timer operations? What about dialog fr_timer and
fr_inv_timer, do they continue to run?
Thanks, really looking forward to async!
-Brett
On Tue, Sep 2, 2014 at 11:26 AM, Răzvan Crainea <raz...@opensips.org
<mailto:raz...@opensips.org>> wrote:
Hi all,
Among the last discussion of the last IRC meeting[1] was related
to Asynchronous processing in OpenSIPS script - we want to add a
new mechanism that allows you to perform asynchronous operations
(such as DB , REST or exec operations) directly from the script.
Using this feature will increase the throughput of OpenSIPS, since
the SIP processes will no longer be stuck waiting for I/O responses.
When reaching an asynchronous operation, the SIP message
processing will be stopped, and resumed in a different script
route. In the script, this should be reflected something like this:
route {
...
# other non I/O operations
async(my_resume_route) {
avp_db_query("SELECT setid from subscribers where username
= '$fU'", "$avp(setid)");
}
# we never get here.
exit;
}
route[my_resume_route] {
xlog("The set used by the callee is $avp(setid)\n");
# continue message processing
}
Only the functions that are used in an "async" block will be ran
asynchronously. If the function does not support async processing,
it will block waiting for the response and resume in the route
indicated by the "async" block - so the scripting experience will
be the same even if the async OP could not be done.
In order to resume the processing in a different route, we need to
store a context of the message. This will be done using the
transaction module[2]. If this module is not used, the
asynchronous mechanism will not work.
lirakis suggested to have different processes that waits for the
asynchronous I/O responses and continues the processing. However,
we think having the SIP worker processes resume the operations
will behave better, since we'll have fewer processes and we won't
loose time with context switches.
How do you see this feature? How would you like to use it? Feel
free to contribute with any input you find suitable!
[1] http://www.opensips.org/Community/IRCmeeting20140827
[2] http://www.opensips.org/html/docs/modules/1.12.x/tm
Best regards,
--
Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com <http://www.opensips-solutions.com>
_______________________________________________
Users mailing list
Users@lists.opensips.org <mailto:Users@lists.opensips.org>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
