21 Nov
2016
21 Nov
'16
6:41 a.m.
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
--
Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 (direct) / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
21 Nov
21 Nov
12:44 p.m.
New subject: async_workers vs. async workers modparam in case of async_route()
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:
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
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Nov 28-30, 2016 - http://www.asipto.com
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?
22 Nov
22 Nov
6:20 a.m.
New subject: async_workers vs. async workers modparam in case of async_route()
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
--
Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 (direct) / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
3:02 p.m.
New subject: async_workers vs. async workers modparam in case of async_route()
On 22/11/2016 06:20, Alex Balashov wrote:
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.
On 11/21/2016 06:44 AM, Daniel-Constantin Mierla
wrote:
Yes -- it's actually mysql that uses them. For postgress I am not sure
if it was developed...
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()?
Yes.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Nov 28-30, 2016 - http://www.asipto.com
2930
days inactive
2931
days old
3 comments
2 participants
participants (2)
-
Alex Balashov -
Daniel-Constantin Mierla