Documentation |
Documentation.Script-Async-3-5 HistoryHide minor edits - Show changes to markup October 24, 2024, at 11:32 AM
by
- Changed lines 171-172 from:
List of async functionsto:
List of async functions 🔗Changed lines 186-187 from:
Limitationsto:
Limitations 🔗Changed lines 233-234 from:
Allowed Routesto:
Allowed Routes 🔗Added line 240:
January 04, 2024, at 11:04 AM
by
- Changed lines 233-236 from:
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: to:
Since the async operations are tightly coupled with the transactional engine, they can only be performed in routes where a SIP transaction is present and is awaiting completion: Changed lines 237-240 from:
Async operations performed on any other route types are subject to undefined behavior. to:
On the other hand, the launch statement should work from any route, as it is not dependent on the underlying SIP transaction. July 14, 2022, at 03:44 PM
by
- Changed line 42 from:
async(blocking_function(...), resume_route); to:
async(blocking_function(...), resume_route [,timeout]); Added lines 53-56:
October 26, 2021, at 03:50 PM
by
- Changed lines 91-92 from:
Parallel asynchronous operationsto:
Parallel asynchronous operations, launch() 🔗Added lines 112-117:
route[report_route] {} or launch(blocking_function(...), report_route, "Something with $var(xx) to be passed to report route"); route[report_route] { xlog("received as input the <$param(1)> string\n"); } October 26, 2021, at 03:47 PM
by
- Changed lines 24-25 from:
to:
Serial asynchronous operations, async() 🔗October 26, 2021, at 03:46 PM
by
- Changed lines 24-25 from:
Serial asynchronous operations - async()to:
October 26, 2021, at 03:42 PM
by
- Changed line 24 from:
Serial asynchronous operationsto:
Serial asynchronous operations - async()January 14, 2021, at 10:56 AM
by
- Changed line 207 from:
TCP connects or little to not at all. For the former case, we suggest forking external processes to:
TCP connects or hardly at all. For the former case, we suggest forking external processes January 14, 2021, at 10:53 AM
by
- Changed lines 43-44 from:
Note that resume_route has to be a simple route. to:
Note that resume_route must be a simple route. Changed line 110 from:
Note that report_route has to be a simple route. to:
Note that report_route must be a simple route. February 03, 2020, at 04:37 PM
by
- Changed line 152 from:
to:
June 28, 2019, at 12:27 AM
by
- Deleted lines 226-229:
June 27, 2019, at 04:31 PM
by
- 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
- 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
- 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
- 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
- Added lines 217-231:
Allowed RoutesSince 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:
Async operations performed on any other route types are subject to undefined behavior. June 27, 2019, at 01:09 PM
by - June 27, 2019, at 01:08 PM
by
- Changed lines 212-213 from:
to:
Changed line 216 from:
to:
June 27, 2019, at 01:08 PM
by
- 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
- 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
- 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. LimitationsAsync Engine CompatibilityThe 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:
TCP Connect IssuesAlthough 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!
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:
or
August 23, 2017, at 04:17 PM
by
- Added line 167:
April 26, 2017, at 04:27 PM
by
- 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
- Changed line 29 from:
to:
April 26, 2017, at 04:06 PM
by
- 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
- Added line 165:
April 26, 2017, at 04:00 PM
by
- Deleted line 106:
Deleted line 107:
April 26, 2017, at 03:59 PM
by
- Changed line 95 from:
to:
April 26, 2017, at 03:59 PM
by
- Changed line 94 from:
to:
April 26, 2017, at 03:58 PM
by
- 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:
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.
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"); }
Ignored data (not available anymore in report route)
April 26, 2017, at 03:32 PM
by
- Added lines 72-73:
... t_relay(); April 26, 2017, at 03:31 PM
by
- Added lines 48-49:
\\ April 26, 2017, at 03:30 PM
by
- Changed lines 18-19 from:
Asynchronous script operations are one of the key features of OpenSIPS 3.5. 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:
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
- Deleted lines 83-86:
RequirementsThe 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
- Changed lines 24-25 from:
Module requirementsto:
Serial asynchronous operationsLorem ipsum ... RequirementsChanged lines 32-33 from:
Script syntax and usageto:
Script syntax and usageAdded lines 80-89:
Parallel asynchronous operationsLorem ipsum ... RequirementsThe 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 usageNovember 04, 2016, at 08:06 PM
by
- Added line 85:
March 06, 2015, at 01:36 PM
by
- Added line 3:
This page has been visited 753 times. March 06, 2015, at 01:34 PM
by
- Changed lines 81-82 from:
to:
February 17, 2015, at 06:50 PM
by
- Changed line 17 from:
Asynchronous script operations are one of the key features of OpenSIPS 3.5. 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.5. 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
- 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
- Changed line 17 from:
Asynchronous script operations are one of the key features of OpenSIPS 3.5. 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.5. 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
- Changed line 17 from:
One of the key features of OpenSIPS 3.5 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.5. 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
- 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
- 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
- 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
- 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
- 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
- Changed lines 1-2 from:
Documentation -> Manuals -> Manual 3.5 -> Asynchronous Statement(:title Asynchronous Statement - 3.5:) to:
Documentation -> Manuals -> Manual 3.5 -> Asynchronous Statements(:title Asynchronous Statements - 3.5:) Changed line 8 from:
to:
January 26, 2015, at 05:16 PM
by
- Deleted lines 74-75:
Changed lines 77-79 from:
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. January 26, 2015, at 05:14 PM
by
- Added line 38:
January 26, 2015, at 05:14 PM
by
- 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
- Changed line 17 from:
One of the key features of OpenSIPS 3.5 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.5 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
- Changed line 17 from:
One of the key features of OpenSIPS 3.5 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.5 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
- 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
- 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
- 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
- Changed line 31 from:
async(blocking_function, resume_route) to:
async(blocking_function(...), resume_route); January 26, 2015, at 03:24 PM
by
- 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
- 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
- Changed line 2 from:
(:title Asynchronous functions - 3.5:) to:
(:title Asynchronous Statement - 3.5:) January 26, 2015, at 03:17 PM
by
- Changed line 1 from:
Documentation -> Manuals -> Manual 3.5 -> Asynchronous Functionsto:
Documentation -> Manuals -> Manual 3.5 -> Asynchronous StatementChanged lines 8-9 from:
to:
Changed line 73 from:
to:
January 26, 2015, at 03:16 PM
by
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- Changed lines 17-19 from:
One of the key features of OpenSIPS 3.5 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 & behaviourto:
One of the key features of OpenSIPS 3.5 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.
Module requirementsThe 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 usageUsage 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
- Changed line 17 from:
One of the key features of OpenSIPS 3.5 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.5 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
- 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
- Changed line 17 from:
One of the key features of OpenSIPS 3.5 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.5 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
- Changed line 15 from:
Introductionto:
DescriptionJanuary 26, 2015, at 01:23 PM
by
- Changed lines 59-61 from:
to:
January 26, 2015, at 01:22 PM
by - January 26, 2015, at 01:21 PM
by
- Changed lines 53-57 from:
Functions with asynchronous versionsto:
List of async functionsThe following functions also have an async version: \\ January 26, 2015, at 01:20 PM
by
- 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:
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
January 26, 2015, at 01:12 PM
by
- 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
- Changed lines 32-33 from:
@] to:
Added line 37:
@] January 26, 2015, at 01:07 PM
by
- Changed lines 17-18 from:
Some of the key features of OpenSIPS 3.5 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.5 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)
Ignored data (not available anymore in resume route)
January 26, 2015, at 12:55 PM
by
- Changed line 22 from:
route [ ... to:
route January 26, 2015, at 12:55 PM
by
- Added line 22:
route [ ... January 26, 2015, at 12:54 PM
by
- Changed line 26 from:
/* script is stopped right away! */ to:
/* script execution is paused right away! */ January 26, 2015, at 12:54 PM
by
- Added line 22:
{ Deleted line 25:
Added line 27:
} January 26, 2015, at 12:54 PM
by
- Changed lines 17-21 from:
One of the key features of OpenSIPS 3.5 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 behaviourWhen a function is called in an asynchronous manner, the script is paused to:
Some of the key features of OpenSIPS 3.5 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
- Added lines 15-21:
IntroductionOne of the key features of OpenSIPS 3.5 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 behaviourWhen a function is called in an asynchronous manner, the script is paused January 26, 2015, at 12:27 PM
by
- Added lines 1-15:
Documentation -> Manuals -> Manual 3.5 -> Asynchronous Functions(:title Asynchronous functions - 3.5:) (:allVersions Script-Async 3.5:)
(: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. |