On 02 Sep 2014, at 18:26, Răzvan Crainea <[email protected]> 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.
I find this quite problematic. How does John Doe know a function supports async
or not? Maybe the configuration checker can know this and not let OpenSIPS
start if you are doing it wrong? Alternatively, blocking functions could be ran
in a thread pool thus giving the illusion of them being async.
Regards,
--
Saúl Ibarra Corretgé
AG Projects
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
