20 Feb
2018
20 Feb
'18
3:58 p.m.
Hi list,
I am looking at the python script reload functionality exposed by the
rpc command "app_python.reload" and implemented by the function
app_python_rpc_reload.
The implementation increments a version number and calls
apy_reload_script(). But it looks like apy_reload_script() would be
run invoked in the process where the RPC server lives rather than the
children.
How is it sent to the workers for invocation?
I think I am misunderstanding how the RPC server works: how do you
differentiate between RPC functions meant to be executed by the master
vs sent to all the slaves?
Thanks
Anthony
20 Feb
20 Feb
4:35 p.m.
New subject: question on RPC script reload: how is it invoked in the workers?
Hello,
the script reload mechanism relies on a counter (version number) stored
in shared memory. It is set to 0 when kamailio start and increased with
each RPC reload command.
Each worker process has a copy of the value in a local variable.
When a worker process is executing a script, it checks if the local
value matches the one from shared memory. If different, then it should
reload the script before executing it.
This is how is done for Lua, JavaScript and Squirrel. I tried to
implement the same for app_python, but I couldn't make it work properly
due to lack of (embedding) python experience.
Cheers,
Daniel
On 20.02.18 15:58, Anthony Alba wrote:
Hi list,
I am looking at the python script reload functionality exposed by the
rpc command "app_python.reload" and implemented by the function
app_python_rpc_reload.
The implementation increments a version number and calls
apy_reload_script(). But it looks like apy_reload_script() would be
run invoked in the process where the RPC server lives rather than the
children.
How is it sent to the workers for invocation?
I think I am misunderstanding how the RPC server works: how do you
differentiate between RPC functions meant to be executed by the master
vs sent to all the slaves?
Thanks
Anthony
_______________________________________________
Kamailio (SER) - Development Mailing List
sr-dev(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
--
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - March 5-7, 2018, Berlin - www.asipto.com
Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com
21 Feb
21 Feb
12:45 a.m.
New subject: question on RPC script reload: how is it invoked in the workers?
On Tue, Feb 20, 2018 at 04:35:01PM +0100, Daniel-Constantin Mierla wrote:
the script reload mechanism relies on a counter
(version number) stored
in shared memory. It is set to 0 when kamailio start and increased with
each RPC reload command.
Each worker process has a copy of the value in a local variable.
When a worker process is executing a script, it checks if the local
value matches the one from shared memory. If different, then it should
reload the script before executing it.
Hi, I cannot see the reload taking effect in the workers, only in the child of rank -2
I have a test script that prints out a "version" number. When I increment
the version number and use kamcmd app_python.reload I can see it reloaded in
one child (rank -2, RPC server?). The other workers don't seem to check the version
number and
reload themselves.
# Start: version == 9
# this from master: 9 is version
INFO: <core> [core/kemi.c:91]: sr_kemi_core_info(): 9
/usr/local/etc/kamailio/handler.py is loaded
# this from each child, 9 is version, last digit is rank of child
INFO: <core> [core/kemi.c:91]: sr_kemi_core_info(): 9 child is launched 0
INFO: <core> [core/kemi.c:91]: sr_kemi_core_info(): 9 child is launched 1
INFO: <core> [core/kemi.c:91]: sr_kemi_core_info(): 9 child is launched 2
# process some SIP... print version:rank and From: header
# it seems that the SIP workers are ranks 1,2 not -2
INFO: <core> [core/kemi.c:91]: sr_kemi_core_info(): 9:1
<sip:testing@example.com>;tag=5aecee01-7109-481d-9b20-4beab44f0928
# repeat until all workers have at least run the script once
# Update: version == 10, reload script...
INFO: app_python3 [apy_kemi.c:1204]: app_python_rpc_reload(): marking for reload js script
file: /usr/local/etc/kamailio/handler.py (0 => 0)
INFO: <core> [core/kemi.c:91]: sr_kemi_core_info(): 10
/usr/local/etc/kamailio/handler.py is loaded
INFO: <core> [core/kemi.c:91]: sr_kemi_core_info(): 10 child is launched -2
I see that the child of rank -2 has reloaded and prints 10 (the new version)
However workers of rank 1, 2 use old script (the RPC reload command is not propagated)
# from worker 2
INFO: <core> [core/kemi.c:91]: sr_kemi_core_info(): 9:2
<sip:testing@example.com>;tag=8eb80965-879d-4cef-bcc0-76e45e485821
The script version is checked in apy_reload_script(); this seems to be run directly in the
RPC server(?)(rank: -2) but
I can't see where it schedules apy_reload_script() in the other workers.
Anthony
12:59 a.m.
New subject: question on RPC script reload: how is it invoked in the workers?
On Tue, Feb 20, 2018 at 04:35:01PM +0100, Daniel-Constantin Mierla wrote:
Hello,
the script reload mechanism relies on a counter (version number) stored
in shared memory. It is set to 0 when kamailio start and increased with
each RPC reload command.
Each worker process has a copy of the value in a local variable.
More details:
The script is reloaded only if the process calls the function apy_reload_script().
There are processes which are not SIP workers ranks: 0, -1, -2, -4.
SIP workers have ranks: 1, 2
It would appear that the RPC server is in -2: I can see it reload the script in itself:
it calls apy_reload_script() which calls apy_load_script()/apy_init_script()
However I don't see worker -2 instruct workers 1,2 to run apy_load_script().
What I need is a mechanism to schedule a function call in the workers: something like
// pseudo-code
for (i = 1, i < 3; i++)
// run_in_worker(int rank, void* function)
run_in_worker(1, apy_reload_script);
Anthony
2474
days inactive
2474
days old
3 comments
2 participants
participants (2)
-
Anthony Alba -
Daniel-Constantin Mierla