Documentation

Documentation.Script-Async-3-1 History

Hide minor edits - Show changes to markup

February 03, 2020, at 04:37 PM by liviu -
Changed line 152 from:
  • only $avp variables set by the async function
to:
  • output variables set by the async function
June 28, 2019, at 12:27 AM by liviu -
Deleted lines 226-229:
  • 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:31 PM by liviu -
Changed line 207 from:

TCP connects or little to no at all. For the former case, we suggest forking external processes

to:

TCP connects or little to not at all. For the former case, we suggest forking external processes

June 27, 2019, at 03:33 PM by liviu -
Changed lines 220-221 from:

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

to:

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.

June 27, 2019, at 02:15 PM by liviu -
Changed lines 221-222 from:

can only be launched in routes where a SIP transaction is present and still awaiting completion. This includes:

to:

can only be launched in routes where a SIP transaction is present and is still awaiting completion. This includes:

June 27, 2019, at 02:14 PM by liviu -
Changed line 221 from:

can only be launched in routes where the SIP transaction is still awaiting completion. This includes:

to:

can only be launched in routes where a SIP transaction is present and still awaiting completion. This includes:

June 27, 2019, at 02:12 PM by liviu -
Added lines 217-231:

Allowed Routes

Since the async engine is tightly coupled with the transactional engine, async operations, at minimal, can only be launched in routes where the SIP transaction 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.

June 27, 2019, at 01:09 PM by liviu -
June 27, 2019, at 01:08 PM by liviu -
Changed lines 212-213 from:

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

to:

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

Changed line 216 from:

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

to:

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

June 27, 2019, at 01:08 PM by liviu -
Changed line 204 from:
  each connection is a blocking operation, and cannot be made async due to library limitations.
to:
  each connection is a blocking operation, and cannot be made async due to the nature of the library.
June 27, 2019, at 01:06 PM by liviu -
Changed lines 176-178 from:

The async engine is heavily dependent on 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:

to:

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:

June 27, 2019, at 01:05 PM by liviu -
Changed lines 170-216 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 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 library limitations.

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(out)), resume_route);

or

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

August 23, 2017, at 04:17 PM by liviu -
Added line 167:
  • ldap_search
April 26, 2017, at 04:27 PM by liviu -
Changed line 114 from:

The launch() statement is both asynchronous and parallel with the script execution that follows it (see below). The script writer must take this into consideration if also designing a "report_route", as it may be triggered at any of the following points in time:

to:

The launch() statement is both asynchronous and parallel with the script execution that follows it (see below). Notice how the "report_route" can be omitted, as script execution does not depend on it. This route may be triggered at any of the following points in time:

April 26, 2017, at 04:06 PM by liviu -
Changed line 29 from:
  • perform an HTTP query and act depending on its result
to:
  • perform an HTTP query and act upon its result
April 26, 2017, at 04:06 PM by liviu -
Changed line 22 from:

Using the asynchronous, "suspend-resume" logic instead of forking a large number of processes in order to scale also has the advantage of optimizing system resource usage. 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 the asynchronous, "suspend-resume" logic instead of forking a large number of processes in order to scale also has the advantage of optimizing system resource usage, increasing its maximal throughput. 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.

April 26, 2017, at 04:04 PM by liviu -
Added line 165:
  • rest_put
April 26, 2017, at 04:00 PM by liviu -
Deleted line 106:
Deleted line 107:
April 26, 2017, at 03:59 PM by liviu -
Changed line 95 from:
  • push data into a database (e.g. call statistics, CDRs, etc.)
to:
  • push data into a custom database (e.g. call statistics, CDRs, etc.)
April 26, 2017, at 03:59 PM by liviu -
Changed line 94 from:
  • exec a push notification trigger
to:
  • execute an external push notification trigger
April 26, 2017, at 03:58 PM by liviu -
Changed lines 92-93 from:

Lorem ipsum ...

to:

The launch() statement of the OpenSIPS script can be used in situations where the script writer needs to perform blocking I/O, but does not depend on the result of this operation in order to continue the current SIP routing decision flow. Some example scenarios:

  • exec a push notification trigger
  • push data into a database (e.g. call statistics, CDRs, etc.)
  • notify an HTTP service of the occurrence of an event (e.g. SIP traffic pattern, fraud detection, etc.)


The launch() statement comes with no additional module dependencies.

Added lines 103-158:

Similarly to the async() statement, if your blocking function supports asynchronous mode (read the module documentation for this), then you can just throw it in the following function calls:

launch(blocking_function(...));

or

launch(blocking_function(...), report_route);

Note that report_route has to be a simple route.


The launch() statement is both asynchronous and parallel with the script execution that follows it (see below). The script writer must take this into consideration if also designing a "report_route", as it may be triggered at any of the following points in time:

  • right before the next code line following the launch() call
  • during the routing of the current SIP message
  • after the routing of the current SIP message


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


route
{
    /* preparation code */
    ...

    # send a push notification asynchronously, in parallel
    launch(exec("/usr/local/bin/send-google-pn.py"), pn_counter);
    t_relay();
}

route [pn_counter]
{
    if ($rc < 0) {
        xlog("error $rc in pn script!\n");
        update_stat("pn-failure", "1");
        exit;
    }

    update_stat("pn-success", "1");
}


Preserved data (still available in report route)

  • only $avp variables set by the async function

Ignored data (not available anymore in report route)

  • any other variable
  • the initial SIP message
April 26, 2017, at 03:32 PM by liviu -
Added lines 72-73:
    ...
    t_relay();
April 26, 2017, at 03:31 PM by liviu -
Added lines 48-49:

\\

April 26, 2017, at 03:30 PM by liviu -
Changed lines 18-19 from:

Asynchronous script operations are one of the key features of OpenSIPS 3.1. 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.

to:

Asynchronous statements are one of the key features of OpenSIPS 2.X. One of the main reasons to use them 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.

Changed lines 22-23 from:

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.

to:

Using the asynchronous, "suspend-resume" logic instead of forking a large number of processes in order to scale also has the advantage of optimizing system resource usage. 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.

Changed lines 26-27 from:

Lorem ipsum ...

to:

The async() statement of the OpenSIPS script can be used in situations where the script writer both needs to perform blocking I/O and also depends on the result of this operation. Some example scenarios:

  • fetch SIP authentication data from a database
  • perform an HTTP query and act depending on its result
  • pause script execution for X seconds
  • exec an external script and use its result
Changed lines 35-36 from:

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).

to:

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

Changed line 39 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:

to:

Usage is 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:

Changed lines 47-49 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 run the given resume route and continue processing, with a minimum of idle time.

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:

Because the async() statement is serial with script execution (see below), the script will be immediately halted when calling it, so any code placed 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 resume route - thus resuming script execution with a minimum of idle time.

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 output parameters (variables in function parameters used to carry output values) will be available in resume route.

April 26, 2017, at 03:07 PM by liviu -
Deleted lines 83-86:

Requirements

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).

April 26, 2017, at 03:06 PM by liviu -
Changed lines 24-25 from:

Module requirements

to:

Serial asynchronous operations

Lorem ipsum ...

Requirements

Changed lines 32-33 from:

Script syntax and usage

to:

Script syntax and usage

Added lines 80-89:

Parallel asynchronous operations

Lorem ipsum ...

Requirements

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).

Script syntax and usage

November 04, 2016, at 08:06 PM by liviu -
Added line 85:
  • sleep
March 06, 2015, at 01:36 PM by liviu -
Added line 3:

This page has been visited 841 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 3.1. 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 3.1. 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 3.1. 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 3.1. 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 3.1 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 3.1. 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 3.1 -> Asynchronous Statement

(:title Asynchronous Statement - 3.1:)

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

(:title Asynchronous Statements - 3.1:)

Changed line 8 from:
Asynchronous Statement v3.1
to:
Asynchronous Statements v3.1
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 3.1 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 3.1 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 3.1 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 3.1 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 - 3.1:)

to:

(:title Asynchronous Statement - 3.1:)

January 26, 2015, at 03:17 PM by liviu -
Changed line 1 from:
Documentation -> Manuals -> Manual 3.1 -> Asynchronous Functions
to:
Documentation -> Manuals -> Manual 3.1 -> Asynchronous Statement
Changed lines 8-9 from:
Asynchronous Functions v3.1
to:
Asynchronous Statement v3.1
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 3.1 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 3.1 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 3.1 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 3.1 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 3.1 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 3.1 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 3.1 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 3.1 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 3.1 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 3.1 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 3.1 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 3.1 -> Asynchronous Functions

(:title Asynchronous functions - 3.1:)


(:allVersions Script-Async 3.1:)


Asynchronous Functions v3.1
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 February 03, 2020, at 04:37 PM