Hi,
If I am using async_route() with delay, what is the relationship between the core async_workers parameter value and the async module 'workers' modparam?
This doc change was intended to clarify it, I think:
https://www.mail-archive.com/sr-dev@lists.sip-router.org/msg25002.html
But it does not for me:
Number of worker processes to be started to handle the asynchronous tasks for async_route() and async_sleep().
So, does that mean the module starts its own processes for these cases? If so, does that mean I don't need core async_workers at all? Or do I? If I do, what happens if I have fewer core async_workers than modparam workers? What if I have more? Should I aim to keep them in sync?
Thanks,
-- Alex
Hello,
On 21/11/16 06:41, Alex Balashov wrote:
Hi,
If I am using async_route() with delay, what is the relationship between the core async_workers parameter value and the async module 'workers' modparam?
This doc change was intended to clarify it, I think:
https://www.mail-archive.com/sr-dev@lists.sip-router.org/msg25002.html
But it does not for me:
Number of worker processes to be started to handle the asynchronous tasks for async_route() and async_sleep().
So, does that mean the module starts its own processes for these cases? If so, does that mean I don't need core async_workers at all? Or do I? If I do, what happens if I have fewer core async_workers than modparam workers? What if I have more? Should I aim to keep them in sync?
the workers param for async module was added with the first implementation of the module, as a proof of how to do async ops in kamailio.cfg besides the t_suspend()/t_continue().
As there were more components getting to do async ops, I added async_workers in the core so a common pool of extra processes is created and can be shared by many modules.
At this moment, from what I remember by heart, mysql module and async (when using async_task_route()) use async_workers from the core.
I don't recall exactly, but somehow I planned to switch async module to use only processes from the core, but I thought that it can break existing configs.
To answer further, you don't need to keep them in sycn and you don't need core async workers if you use only async_route() (or async_sleep(), but this one has some traps highlighted in the readme, so I try not to promote it that much).
Cheers, Daniel
On 11/21/2016 06:44 AM, Daniel-Constantin Mierla wrote:
At this moment, from what I remember by heart, mysql module and async (when using async_task_route()) use async_workers from the core.
What about sql_query_async()? I assume that uses core async_workers too.
I don't recall exactly, but somehow I planned to switch async module to use only processes from the core, but I thought that it can break existing configs.
To answer further, you don't need to keep them in sycn and you don't need core async workers if you use only async_route() (or async_sleep(), but this one has some traps highlighted in the readme, so I try not to promote it that much).
What kind of traps? :-) I don't really see anything in the docs for async_asleep() that sets off alarm bells in my mind.
At the moment I'm only using async_route(), yet this is the process situation:
[root@allegro-4 routes]# kamcmd -s /tmp/kamailio_ctl ps 27621 main process - attendant 27623 udp receiver child=0 sock=10.150.20.6:5060 27624 udp receiver child=1 sock=10.150.20.6:5060 27625 udp receiver child=2 sock=10.150.20.6:5060 27626 udp receiver child=3 sock=10.150.20.6:5060 27627 udp receiver child=4 sock=10.150.20.6:5060 27629 udp receiver child=5 sock=10.150.20.6:5060 27630 udp receiver child=6 sock=10.150.20.6:5060 27632 udp receiver child=7 sock=10.150.20.6:5060 27635 slow timer 27638 timer 27639 secondary timer 27641 Async Task Worker 27642 Async Task Worker 27644 Async Task Worker 27647 Async Task Worker 27650 Async Task Worker 27652 Async Task Worker 27654 Async Task Worker 27656 Async Task Worker 27658 MI FIFO 27661 ctl handler 27663 RTIMER USEC EXEC 27664 RTIMER USEC EXEC 27666 RTIMER USEC EXEC 27669 RTIMER USEC EXEC 27672 RTIMER USEC EXEC 27674 RTIMER USEC EXEC 27676 RTIMER USEC EXEC 27678 ASYNC MOD TIMER 27680 ASYNC MOD TIMER 27682 ASYNC MOD TIMER 27684 ASYNC MOD TIMER 27686 ASYNC MOD TIMER 27688 ASYNC MOD TIMER 27690 ASYNC MOD TIMER 27692 ASYNC MOD TIMER 27694 Dialog KA Timer 27696 Dialog Clean Timer 27700 tcp main process
So it is safe to remove the async_workers declaration entirely or set it to 0, and I can still benefit from 8 async processes for async_route()?
-- Alex
On 22/11/2016 06:20, Alex Balashov wrote:
On 11/21/2016 06:44 AM, Daniel-Constantin Mierla wrote:
At this moment, from what I remember by heart, mysql module and async (when using async_task_route()) use async_workers from the core.
What about sql_query_async()? I assume that uses core async_workers too.
Yes -- it's actually mysql that uses them. For postgress I am not sure if it was developed...
I don't recall exactly, but somehow I planned to switch async module to use only processes from the core, but I thought that it can break existing configs.
To answer further, you don't need to keep them in sycn and you don't need core async workers if you use only async_route() (or async_sleep(), but this one has some traps highlighted in the readme, so I try not to promote it that much).
What kind of traps? :-) I don't really see anything in the docs for async_asleep() that sets off alarm bells in my mind.
A return from inside the route block done after async_sleep() is like an exit. Also, the private memory variables (e.g., $var(...)) are not propagated with the same values after this function. Well these are common for async switching.
At the moment I'm only using async_route(), yet this is the process situation:
[root@allegro-4 routes]# kamcmd -s /tmp/kamailio_ctl ps 27621 main process - attendant 27623 udp receiver child=0 sock=10.150.20.6:5060 27624 udp receiver child=1 sock=10.150.20.6:5060 27625 udp receiver child=2 sock=10.150.20.6:5060 27626 udp receiver child=3 sock=10.150.20.6:5060 27627 udp receiver child=4 sock=10.150.20.6:5060 27629 udp receiver child=5 sock=10.150.20.6:5060 27630 udp receiver child=6 sock=10.150.20.6:5060 27632 udp receiver child=7 sock=10.150.20.6:5060 27635 slow timer 27638 timer 27639 secondary timer 27641 Async Task Worker 27642 Async Task Worker 27644 Async Task Worker 27647 Async Task Worker 27650 Async Task Worker 27652 Async Task Worker 27654 Async Task Worker 27656 Async Task Worker 27658 MI FIFO 27661 ctl handler 27663 RTIMER USEC EXEC 27664 RTIMER USEC EXEC 27666 RTIMER USEC EXEC 27669 RTIMER USEC EXEC 27672 RTIMER USEC EXEC 27674 RTIMER USEC EXEC 27676 RTIMER USEC EXEC 27678 ASYNC MOD TIMER 27680 ASYNC MOD TIMER 27682 ASYNC MOD TIMER 27684 ASYNC MOD TIMER 27686 ASYNC MOD TIMER 27688 ASYNC MOD TIMER 27690 ASYNC MOD TIMER 27692 ASYNC MOD TIMER 27694 Dialog KA Timer 27696 Dialog Clean Timer 27700 tcp main process
So it is safe to remove the async_workers declaration entirely or set it to 0, and I can still benefit from 8 async processes for async_route()?
Yes.
Cheers, Daniel
-
Alex Balashov -
Daniel-Constantin Mierla