Documentation

Documentation.Script-Async-2-2 History

Hide minor edits - Show changes to markup

June 28, 2019, at 12:28 AM by liviu -
Deleted lines 144-147:
  • event_route... situationally. If the event is triggered inline with a SIP transaction (e.g. E_UL_CONTACT_INSERT on a save() operation), then async will work. Otherwise, if the event is not tied to a SIP transaction (e.g. E_FREESWITCH incoming ESL event), then async will not work.
June 27, 2019, at 04:34 PM by liviu -
Changed lines 130-131 from:

async(exec("curl my_host", $var(response_body)), resume_route);

to:

async(exec("curl my_host", "$var(response_body)"), resume_route);

Changed line 134 from:

async(exec("mysql-query 'SELECT * FROM subscriber...'", $var(result_row)), resume_route);

to:

async(exec("mysql-query 'SELECT * FROM subscriber...'", "$var(result_row)"), resume_route);

June 27, 2019, at 04:29 PM by liviu -
Changed lines 88-150 from:

The async implementation is not limited to the above functions, but these are the first ones migrated to async support. More I/O related functions will be ported to the async support.

to:

The async implementation is not limited to the above functions, but these are the first ones migrated to async support. More I/O related functions will be ported to the async support.

Limitations

Async Engine Compatibility

The async engine is heavily dependent on non-blocking I/O features exposed by the underlying libraries -- a blocking I/O operation, such as an HTTP or an SQL query can only be made asynchronous if the library additionally provides both:

  • a non-blocking equivalent of the same, originally blocking function
  • after the non-blocking equivalent function is launched, the library must also provide a mechanism to extract a valid Linux file descriptor corresponding to the data transfer operation that has just been launched. The OpenSIPS async engine will poll on this fd, and will trigger internal state updates each time new data is available. When the blocking operation is finished, the "resume route" gets called, and the async operation is finalized.

TCP Connect Issues

Although they provide async functionality, some libraries only do this for the "transfer" part of the I/O operation, and NOT the initial TCP connect. Consequently, on some corner-case scenarios (e.g. the TCP connect hangs due to an unresponsive server, an in-between firewall which drops packets instead of rejecting them, etc.) the async operation may actually block!


Examples of modules which are affected by this limitation:

  • rest_client - although it reuses TCP connections on further requests, libcurl will block until a TCP connection is established from a given OpenSIPS worker. Should these TCP connects ever hang, so will the corresponding OpenSIPS worker.
  • db_mysql - similar to rest_client: although it reuses DB connections heavily, establishing each connection is a blocking operation, and cannot be made async due to the nature of the library.

Mitigation: depending on your specific setup, you may be severely impacted by these blocking TCP connects or little to no at all. For the former case, we suggest forking external processes responsible for your blocking operations and invoke them asynchronously, using constructs such as:


async(exec("curl my_host", $var(response_body)), resume_route);

or

async(exec("mysql-query 'SELECT * FROM subscriber...'", $var(result_row)), resume_route);

Allowed Routes

Since the async engine is tightly coupled with the transactional engine, async operations can, at best, only be launched in routes where a SIP transaction is present and is still awaiting completion. This includes:

  • request_route
  • onreply_route
  • local_route
  • event_route... situationally. If the event is triggered inline with a SIP transaction (e.g. E_UL_CONTACT_INSERT on a save() operation), then async will work. Otherwise, if the event is not tied to a SIP transaction (e.g. E_FREESWITCH incoming ESL event), then async will not work.

Async operations performed on any other route types are subject to undefined behavior.

August 23, 2017, at 04:18 PM by liviu -
Added line 85:
  • ldap_search
November 28, 2016, at 11:30 AM by 109.99.227.30 -
Changed line 1 from:
Documentation -> Manuals -> Manual devel -> Asynchronous Statements
to:
Documentation -> Manuals -> Manual 2.2 -> Asynchronous Statements
November 04, 2016, at 08:08 PM by liviu -
Added line 85:
  • sleep
March 06, 2015, at 01:36 PM by liviu -
Added line 3:

This page has been visited 7214 times.

March 06, 2015, at 01:34 PM by liviu -
Changed lines 81-82 from:
  • rest_get
to:
  • rest_get
  • rest_post
February 17, 2015, at 06:50 PM by liviu -
Changed line 17 from:

Asynchronous script operations are one of the key features of OpenSIPS 2.2. Their main advantage is that they allow the performance of the OpenSIPS script to scale with a high number of requests per second even when doing blocking I/O operations such as MySQL queries, exec commands or HTTP requests.

to:

Asynchronous script operations are one of the key features of OpenSIPS 2.2. The main advantage of using them is the fact that they allow the performance of the OpenSIPS script to scale with a high number of requests per second even when doing blocking I/O operations such as MySQL queries, exec commands or HTTP requests.

February 04, 2015, at 11:04 PM by liviu -
Changed line 33 from:

Note that resume_route has to be a simple route.

to:

Note that resume_route has to be a simple route.

February 04, 2015, at 11:01 PM by liviu -
Changed line 17 from:

Asynchronous script operations are one of the key features of OpenSIPS 2.2. Their main advantage is that they allow the performance of the OpenSIPS script to scale with a high number of requests per second even when doing blocking I/O operations such as MySQL queries, exec commands or HTTP GET operations.

to:

Asynchronous script operations are one of the key features of OpenSIPS 2.2. Their main advantage is that they allow the performance of the OpenSIPS script to scale with a high number of requests per second even when doing blocking I/O operations such as MySQL queries, exec commands or HTTP requests.

January 26, 2015, at 07:23 PM by liviu -
Changed line 17 from:

One of the key features of OpenSIPS 2.2 are asynchronous script operations. Their main advantage is that they allow the performance of the OpenSIPS script to scale with a high number of requests per second even when doing blocking I/O operations such as MySQL queries, exec commands or HTTP GET operations.

to:

Asynchronous script operations are one of the key features of OpenSIPS 2.2. Their main advantage is that they allow the performance of the OpenSIPS script to scale with a high number of requests per second even when doing blocking I/O operations such as MySQL queries, exec commands or HTTP GET operations.

January 26, 2015, at 05:46 PM by liviu -
Changed line 59 from:
    xlog("Great! Credit of user $avp(uid) is $avp(credit)\n");
to:
    xlog("Credit of user $avp(uid) is $avp(credit)\n");
January 26, 2015, at 05:45 PM by liviu -
Changed lines 54-55 from:
    xlog("avp_db_query() returned with $rc\n");
    xlog("Credit of user $avp(uid) is $avp(credit)\n");
to:
    if ($rc < 0) {
        xlog("error $rc in avp_db_query()\n");
        exit;
    }

    xlog("Great! Credit of user $avp(uid) is $avp(credit)\n");
January 26, 2015, at 05:43 PM by liviu -
Changed lines 54-55 from:
    xlog("Great! Credit of user $avp(uid) is $avp(credit)\n");
to:
    xlog("avp_db_query() returned with $rc\n");
    xlog("Credit of user $avp(uid) is $avp(credit)\n");
January 26, 2015, at 05:40 PM by liviu -
Changed line 39 from:

The return code of the function executed in async mode is available in the very beginning of the resume route in the $rc or $retcode variable. Also, all the output parameters ( variables in function parameters used to carry output values) will be available in resume route.

to:

The return code of the function executed in async mode is available in the very beginning of the resume route in the $rc or $retcode variable. Also, all the output parameters (variables in function parameters used to carry output values) will be available in resume route.

January 26, 2015, at 05:39 PM by liviu -
Changed line 37 from:

When a function is called in the asynchronous manner (see below), the script is immediately halted, so any code you write after the async() call will be ignored! The current OpenSIPS worker will launch the asynchronous operation, after which it will continue to process other pending tasks (queued SIP messages, timer jobs or possibly other async operations!). As soon as all data is available, it will call the given resume route and continue processing, with a minimum of idle time.

to:

When a function is called in the asynchronous manner (see below), the script is immediately halted, so any code you write after the async() call will be ignored! The current OpenSIPS worker will launch the asynchronous operation, after which it will continue to process other pending tasks (queued SIP messages, timer jobs or possibly other async operations!). As soon as all data is available, it will run the given resume route and continue processing, with a minimum of idle time.

January 26, 2015, at 05:23 PM by liviu -
Changed lines 1-2 from:
Documentation -> Manuals -> Manual devel -> Asynchronous Statement

(:title Asynchronous Statement - 2.2:)

to:
Documentation -> Manuals -> Manual devel -> Asynchronous Statements

(:title Asynchronous Statements - 2.2:)

Changed line 8 from:
Asynchronous Statement v2.2
to:
Asynchronous Statements v2.2
January 26, 2015, at 05:16 PM by 89.120.101.121 -
Deleted lines 74-75:


Changed lines 77-79 from:
  • exec
to:
  • exec

The async implementation is not limited to the above functions, but these are the first ones migrated to async support. More I/O related functions will be ported to the async support.

January 26, 2015, at 05:14 PM by 89.120.101.121 -
Added line 38:
January 26, 2015, at 05:14 PM by 89.120.101.121 -
Changed lines 25-26 from:

The asynchronous script logic is based on the transaction module (tm) - it must be loaded. A new transaction is created when every async operation is started. This transaction contains all necessary information to properly suspend script execution (e.g. it stores the updated SIP message, along with all $avp variables). Shortly after the resume route is completed, the transaction will be destroyed.

to:

The asynchronous script logic is based on the transaction module (tm) - it must be loaded. The SIP transaction is automatically and transparently created (if not existing yet) when an async operation is started. This transaction contains all necessary information to properly suspend script execution (e.g. it stores the updated SIP message, along with all $avp variables).

Added line 38:

The return code of the function executed in async mode is available in the very beginning of the resume route in the $rc or $retcode variable. Also, all the output parameters ( variables in function parameters used to carry output values) will be available in resume route.

January 26, 2015, at 04:54 PM by liviu -
Changed line 17 from:

One of the key features of OpenSIPS 2.2 are asynchronous script operations. Their main advantage is that they allow the performance of the OpenSIPS script to scale with a high number of requests per second even when doing blocking I/O operations such as MySQL queries, exec scripts or HTTP GET operations.

to:

One of the key features of OpenSIPS 2.2 are asynchronous script operations. Their main advantage is that they allow the performance of the OpenSIPS script to scale with a high number of requests per second even when doing blocking I/O operations such as MySQL queries, exec commands or HTTP GET operations.

January 26, 2015, at 03:29 PM by liviu -
Changed line 17 from:

One of the key features of OpenSIPS 2.2 are asynchronous script operations. Their main advantage is that they allow the performance of the OpenSIPS script to scale with a high number of requests per second even when doing blocking I/O operations such MySQL queries, exec scripts or HTTP GET operations.

to:

One of the key features of OpenSIPS 2.2 are asynchronous script operations. Their main advantage is that they allow the performance of the OpenSIPS script to scale with a high number of requests per second even when doing blocking I/O operations such as MySQL queries, exec scripts or HTTP GET operations.

January 26, 2015, at 03:29 PM by liviu -
Changed line 33 from:

Note that resume_route has to be a simple route.

to:

Note that resume_route has to be a simple route.

January 26, 2015, at 03:28 PM by liviu -
Changed line 33 from:

Note that the resume route has to be a simple route.

to:

Note that resume_route has to be a simple route.

January 26, 2015, at 03:25 PM by liviu -
Changed line 37 from:

When a function is called in the asynchronous manner (see below), the script is immediately halted, so any code you write after the async() call will be ignored! The current OpenSIPS worker will launch the asynchronous operation, then it will continue to process other pending tasks (queued SIP messages, timer jobs or possibly other async operations!). As soon as all data is available, it will call the given resume route and continue processing, with a minimum of idle time.

to:

When a function is called in the asynchronous manner (see below), the script is immediately halted, so any code you write after the async() call will be ignored! The current OpenSIPS worker will launch the asynchronous operation, after which it will continue to process other pending tasks (queued SIP messages, timer jobs or possibly other async operations!). As soon as all data is available, it will call the given resume route and continue processing, with a minimum of idle time.

January 26, 2015, at 03:24 PM by liviu -
Changed line 31 from:

async(blocking_function, resume_route)

to:

async(blocking_function(...), resume_route);

January 26, 2015, at 03:24 PM by liviu -
Changed lines 29-33 from:

Usage is quite straightforward. If your blocking function supports asynchronous mode (read the module documentation for this), then you can just throw it in the following function call: async(blocking_function, resume_route). Note that the resume route has to be a simple route.

to:

Usage is quite straightforward. If your blocking function supports asynchronous mode (read the module documentation for this), then you can just throw it in the following function call:

async(blocking_function, resume_route)

Note that the resume route has to be a simple route.

January 26, 2015, at 03:20 PM by liviu -
Changed line 21 from:

Using asynchronous logic over simply forking a high number of children (50+ processes) also has the advantage of optimizing the usage of system resources. By requiring less processes to complete the same amount of work in the same amount of time, process context switching is minimized and overall CPU usage is improved. Less processes will also eat up less system memory.

to:

Using asynchronous logic over simply forking a high number of children in order to scale (50+ processes) also has the advantage of optimizing the usage of system resources. By requiring less processes to complete the same amount of work in the same amount of time, process context switching is minimized and overall CPU usage is improved. Less processes will also eat up less system memory.

January 26, 2015, at 03:18 PM by liviu -
Changed line 2 from:

(:title Asynchronous functions - 2.2:)

to:

(:title Asynchronous Statement - 2.2:)

January 26, 2015, at 03:17 PM by liviu -
Changed line 1 from:
Documentation -> Manuals -> Manual devel -> Asynchronous Functions
to:
Documentation -> Manuals -> Manual devel -> Asynchronous Statement
Changed lines 8-9 from:
Asynchronous Functions v2.2
to:
Asynchronous Statement v2.2
Changed line 73 from:
  • exec
to:
  • exec
January 26, 2015, at 03:16 PM by liviu -
Changed lines 33-34 from:

When a function is called in an asynchronous manner (see below), the script is immediately halted, so any code you write after the async() call will be ignored! The current OpenSIPS worker will launch the asynchronous operation, then it will continue to process other pending tasks (queued SIP messages, timer jobs or possibly other async operations!). As soon as the data is available, it will call the given resume route and continue processing, with a minimum of idle time.

to:

When a function is called in the asynchronous manner (see below), the script is immediately halted, so any code you write after the async() call will be ignored! The current OpenSIPS worker will launch the asynchronous operation, then it will continue to process other pending tasks (queued SIP messages, timer jobs or possibly other async operations!). As soon as all data is available, it will call the given resume route and continue processing, with a minimum of idle time.

Changed line 67 from:

The following functions also have an async version:

to:

The following functions may also be called asynchronously:

January 26, 2015, at 03:11 PM by liviu -
Changed line 29 from:

Usage is quite straightforward. If your blocking function supports asynchronous mode (read the module documentation for this), then you can just throw it in the following function call: async(blocking_function, some_resume_route). Note that the resume route has to be a simple route.

to:

Usage is quite straightforward. If your blocking function supports asynchronous mode (read the module documentation for this), then you can just throw it in the following function call: async(blocking_function, resume_route). Note that the resume route has to be a simple route.

January 26, 2015, at 03:11 PM by liviu -
Changed line 29 from:

Usage is quite straightforward. If your blocking function supports asynchronous mode (read the module documentation for this), then you can just throw it in the following function call: async(blocking_function, some_resume_route).

to:

Usage is quite straightforward. If your blocking function supports asynchronous mode (read the module documentation for this), then you can just throw it in the following function call: async(blocking_function, some_resume_route). Note that the resume route has to be a simple route.

January 26, 2015, at 03:08 PM by liviu -
Changed line 29 from:

Usage is quite straightforward. If your blocking function supports asynchronous mode (read the module documentation for this), then you can just throw it in the following function call: async(your_function, your_resume_route).

to:

Usage is quite straightforward. If your blocking function supports asynchronous mode (read the module documentation for this), then you can just throw it in the following function call: async(blocking_function, some_resume_route).

January 26, 2015, at 03:07 PM by liviu -
Changed line 29 from:

Usage is quite straightforward. If your blocking function supports asynchronous mode (read the module documentation for this), then you can just throw it in a async(your_function, your_resume_route) call along with a resume route.

to:

Usage is quite straightforward. If your blocking function supports asynchronous mode (read the module documentation for this), then you can just throw it in the following function call: async(your_function, your_resume_route).

January 26, 2015, at 03:06 PM by liviu -
Changed line 25 from:

The asynchronous script logic is based on the transaction module (tm) - it must be loaded. A new transaction is created when every async operation is started. This transaction contains all necessary information to properly suspend script execution (e.g. it stores the updated SIP message, along with all $avp variables). Shortly after the resume route is completed, this transaction will be destroyed.

to:

The asynchronous script logic is based on the transaction module (tm) - it must be loaded. A new transaction is created when every async operation is started. This transaction contains all necessary information to properly suspend script execution (e.g. it stores the updated SIP message, along with all $avp variables). Shortly after the resume route is completed, the transaction will be destroyed.

January 26, 2015, at 03:06 PM by liviu -
Changed line 25 from:

The asynchronous script logic is based on the transaction module (tm) - it must be loaded. A new transaction is created when every async operation is started. This transaction contains all necessary information to properly suspend script execution. It stores the updated SIP message, along with all $avp variables. Shortly after the resume route is completed, this transaction will be destroyed.

to:

The asynchronous script logic is based on the transaction module (tm) - it must be loaded. A new transaction is created when every async operation is started. This transaction contains all necessary information to properly suspend script execution (e.g. it stores the updated SIP message, along with all $avp variables). Shortly after the resume route is completed, this transaction will be destroyed.

January 26, 2015, at 03:05 PM by liviu -
Changed line 25 from:

The asynchronous script logic is based on the transaction module (tm) - it must be loaded. A new transaction is created when every async operation is started. This transaction contains all necessary information to properly suspend script execution. It stores the updated SIP message, along with all user $avp variables. Shortly after the resume route is completed, this transaction will be destroyed.

to:

The asynchronous script logic is based on the transaction module (tm) - it must be loaded. A new transaction is created when every async operation is started. This transaction contains all necessary information to properly suspend script execution. It stores the updated SIP message, along with all $avp variables. Shortly after the resume route is completed, this transaction will be destroyed.

January 26, 2015, at 03:04 PM by liviu -
Changed line 25 from:

The asynchronous script logic is based on the transaction module (tm) - it must be loaded. A new transaction is created when every async operation is started. The transaction contains all necessary information to properly suspend script execution. It stores the updated SIP message, along with all user $avp variables. Shortly after the resume route is completed, this transaction will be destroyed.

to:

The asynchronous script logic is based on the transaction module (tm) - it must be loaded. A new transaction is created when every async operation is started. This transaction contains all necessary information to properly suspend script execution. It stores the updated SIP message, along with all user $avp variables. Shortly after the resume route is completed, this transaction will be destroyed.

January 26, 2015, at 03:03 PM by liviu -
Changed lines 17-19 from:

One of the key features of OpenSIPS 2.2 are asynchronous script operations. Their main advantage is that they allow the performance of the OpenSIPS script to scale with a high number of requests per second even when doing blocking I/O operations such MySQL queries, exec scripts or HTTP GET operations. Using asynchronous logic over simply forking a high number of children (50+ processes) also has the advantage of optimizing the usage of system resources. By requiring less processes to complete the same amount of work in the same amount of time, process context switching is minimized and overall CPU usage is improved. Less processes will also eat up less system memory.

Script syntax & behaviour

to:

One of the key features of OpenSIPS 2.2 are asynchronous script operations. Their main advantage is that they allow the performance of the OpenSIPS script to scale with a high number of requests per second even when doing blocking I/O operations such MySQL queries, exec scripts or HTTP GET operations.


Using asynchronous logic over simply forking a high number of children (50+ processes) also has the advantage of optimizing the usage of system resources. By requiring less processes to complete the same amount of work in the same amount of time, process context switching is minimized and overall CPU usage is improved. Less processes will also eat up less system memory.

Module requirements

The asynchronous script logic is based on the transaction module (tm) - it must be loaded. A new transaction is created when every async operation is started. The transaction contains all necessary information to properly suspend script execution. It stores the updated SIP message, along with all user $avp variables. Shortly after the resume route is completed, this transaction will be destroyed.

Script syntax and usage

Usage is quite straightforward. If your blocking function supports asynchronous mode (read the module documentation for this), then you can just throw it in a async(your_function, your_resume_route) call along with a resume route.

\\

January 26, 2015, at 02:30 PM by liviu -
Changed line 17 from:

One of the key features of OpenSIPS 2.2 are asynchronous script operations. Their main purpose is to optimize the usage of system resources. By requiring less processes to complete the same amount of work in the same amount of time, process context switching is minimized and overall CPU usage is improved. Less processes will also eat up less system memory.

to:

One of the key features of OpenSIPS 2.2 are asynchronous script operations. Their main advantage is that they allow the performance of the OpenSIPS script to scale with a high number of requests per second even when doing blocking I/O operations such MySQL queries, exec scripts or HTTP GET operations. Using asynchronous logic over simply forking a high number of children (50+ processes) also has the advantage of optimizing the usage of system resources. By requiring less processes to complete the same amount of work in the same amount of time, process context switching is minimized and overall CPU usage is improved. Less processes will also eat up less system memory.

January 26, 2015, at 01:26 PM by liviu -
Changed line 21 from:

When a function is called in an asynchronous manner (see below), the script is immediately halted, so any code you write after the async() call will be ignored! The current OpenSIPS worker will launch the asynchronous operation, then it will continue to process other pending tasks. As soon as the data is available, it will call the given resume route and continue processing, with a minimum of idle time.

to:

When a function is called in an asynchronous manner (see below), the script is immediately halted, so any code you write after the async() call will be ignored! The current OpenSIPS worker will launch the asynchronous operation, then it will continue to process other pending tasks (queued SIP messages, timer jobs or possibly other async operations!). As soon as the data is available, it will call the given resume route and continue processing, with a minimum of idle time.

January 26, 2015, at 01:25 PM by liviu -
Changed line 17 from:

One of the key features of OpenSIPS 2.2 are asynchronous script operations. Their main purpose is to optimize the usage of system resources. By requiring less processes to complete the same amount of work in the same amount of time, process context switching is minimized and CPU usage is improved. Less processes will also eat up less system memory.

to:

One of the key features of OpenSIPS 2.2 are asynchronous script operations. Their main purpose is to optimize the usage of system resources. By requiring less processes to complete the same amount of work in the same amount of time, process context switching is minimized and overall CPU usage is improved. Less processes will also eat up less system memory.

January 26, 2015, at 01:23 PM by liviu -
Changed line 15 from:

Introduction

to:

Description

January 26, 2015, at 01:23 PM by liviu -
Changed lines 59-61 from:
  • avp_db_query
  • rest_get
  • exec
to:
  • avp_db_query
  • rest_get
  • exec
January 26, 2015, at 01:22 PM by liviu -
January 26, 2015, at 01:21 PM by liviu -
Changed lines 53-57 from:

Functions with asynchronous versions

to:

List of async functions

The following functions also have an async version:

\\

January 26, 2015, at 01:20 PM by liviu -
Deleted line 20:
Changed lines 23-24 from:

//

to:


Changed lines 40-41 from:

//

to:


Changed lines 44-46 from:

//

Preserved data (available in resume route)

to:


Preserved data (still available in resume route)

Changed lines 53-54 from:

A Transformation is basically a function that is applied to a variable(script variable, pseudo-variables, AVPS, static strings) to get a special value from it. The value of the original variable is not altered.

to:

Functions with asynchronous versions

  • avp_db_query
  • rest_get
  • exec
January 26, 2015, at 01:12 PM by liviu -
Changed lines 22-23 from:

When a function is called in an asynchronous manner (see below), the script is immediately halted, so any code you write after the async() call will be ignored! Also, please note that only $avp variables are preserved in the resume route, along with all changes in the current SIP message.

to:

When a function is called in an asynchronous manner (see below), the script is immediately halted, so any code you write after the async() call will be ignored! The current OpenSIPS worker will launch the asynchronous operation, then it will continue to process other pending tasks. As soon as the data is available, it will call the given resume route and continue processing, with a minimum of idle time.

//

Added lines 41-45:

//

Data is copied over to the resume route as follows:

//

January 26, 2015, at 01:08 PM by liviu -
Changed lines 32-33 from:

@]

to:
Added line 37:

@]

January 26, 2015, at 01:07 PM by liviu -
Changed lines 17-18 from:

Some of the key features of OpenSIPS 2.2 are asynchronous script operations. Their main purpose is to optimize the usage of system resources. By requiring less processes to complete the same amount of work in the same amount of time, process context switching is minimized and CPU usage is improved. Less processes will also eat up less system memory.

to:

One of the key features of OpenSIPS 2.2 are asynchronous script operations. Their main purpose is to optimize the usage of system resources. By requiring less processes to complete the same amount of work in the same amount of time, process context switching is minimized and CPU usage is improved. Less processes will also eat up less system memory.

Added lines 21-23:

When a function is called in an asynchronous manner (see below), the script is immediately halted, so any code you write after the async() call will be ignored! Also, please note that only $avp variables are preserved in the resume route, along with all changes in the current SIP message.

Changed line 29 from:
    async(avp_db_query("SELECT credit FROM users WHERE uid='$id'", "$avp(credit)"), resume_route);
to:
    async(avp_db_query("SELECT credit FROM users WHERE uid='$avp(uid)'", "$avp(credit)"), resume_credit);
Changed lines 34-46 from:

When a function is called in an asynchronous manner, the script is immediately halted.

to:

route [resume_credit] {

    xlog("Great! Credit of user $avp(uid) is $avp(credit)\n");

}

Preserved data (available in resume route)

  • all $avp variables
  • all changes in current SIP message

Ignored data (not available anymore in resume route)

  • all $var variables
January 26, 2015, at 12:55 PM by liviu -
Changed line 22 from:

route [ ...

to:

route

January 26, 2015, at 12:55 PM by liviu -
Added line 22:

route [ ...

January 26, 2015, at 12:54 PM by liviu -
Changed line 26 from:
    /* script is stopped right away! */
to:
    /* script execution is paused right away! */
January 26, 2015, at 12:54 PM by liviu -
Added line 22:

{

Deleted line 25:
Added line 27:

}

January 26, 2015, at 12:54 PM by liviu -
Changed lines 17-21 from:

One of the key features of OpenSIPS 2.2 are asynchronous script operations. Their main purpose is to optimize the usage of system resources. By requiring less processes to complete the same amount of work in the same amount of time, process context switching is minimized and CPU usage is improved. Less processes will also eat up less system memory.

Script behaviour

When a function is called in an asynchronous manner, the script is paused

to:

Some of the key features of OpenSIPS 2.2 are asynchronous script operations. Their main purpose is to optimize the usage of system resources. By requiring less processes to complete the same amount of work in the same amount of time, process context switching is minimized and CPU usage is improved. Less processes will also eat up less system memory.

Script syntax & behaviour

    /* preparation code */
    ...
    async(avp_db_query("SELECT credit FROM users WHERE uid='$id'", "$avp(credit)"), resume_route);

    /* script is stopped right away! */

When a function is called in an asynchronous manner, the script is immediately halted.

January 26, 2015, at 12:48 PM by liviu -
Added lines 15-21:

Introduction

One of the key features of OpenSIPS 2.2 are asynchronous script operations. Their main purpose is to optimize the usage of system resources. By requiring less processes to complete the same amount of work in the same amount of time, process context switching is minimized and CPU usage is improved. Less processes will also eat up less system memory.

Script behaviour

When a function is called in an asynchronous manner, the script is paused

January 26, 2015, at 12:27 PM by liviu -
Added lines 1-15:
Documentation -> Manuals -> Manual devel -> Asynchronous Functions

(:title Asynchronous functions - 2.2:)


(:allVersions Script-Async 2.2:)


Asynchronous Functions v2.2
PrevNext

(:toc-float Table of Content:)

A Transformation is basically a function that is applied to a variable(script variable, pseudo-variables, AVPS, static strings) to get a special value from it. The value of the original variable is not altered.


Page last modified on June 28, 2019, at 12:28 AM