[OpenSIPS-Users] Asynchronous processing in OpenSIPS 1.12

[Brett Nemeroff]

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> 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
>
>
> _______________________________________________
> 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/20140902/24078cf5/attachment.htm>