[OpenSIPS-Users] Asynchronous processing in OpenSIPS 1.12

[Bogdan-Andrei Iancu]

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 <razvan at opensips.org 
> <mailto:razvan at 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 at lists.opensips.org <mailto:Users at lists.opensips.org>
>     http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20140903/d10ef11a/attachment-0001.htm>