On 03.09.2014 13:02, Saúl Ibarra Corretgé wrote:
On 03 Sep 2014, at 11:59, Bogdan-Andrei Iancu <bog...@opensips.org> wrote:

On 03.09.2014 12:06, Saúl Ibarra Corretgé wrote:
On 02 Sep 2014, at 18:26, Răzvan Crainea <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.
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.
First of all, the function will be documented as supporting Async and the script parser 
may check it (we will export some extra flags for the function to say "it can do 
async").

Secondly, the script will allow you to use any combination of functions and 
script macro - I mean the script will allow you to use an async function in a 
non-async way (and the function will act as sync) or to use a non-async 
function in an async way (the function will act as async and with a jump to 
resume route).

My concern is with that last part: if a function which doesn’t support async is 
called within an async block it will block but then make the jump thus 
deceiving the user into believing it was async when it isn’t. We need to fail 
loudly and tell users they are doing it wrong, iMHO.
Of course, we can detect that at script parsing and decide how to handle it:
    - ignore and do it blocking
    - warning and do it blocking
    - error and do not start.

Regards,
Bogdan

_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Reply via email to