git:master: * Moved lcr module from modules_k to modules and removed it from modules_s .
Module: sip-router Branch: master Commit: a3f16850cd2a897710cb0a56174e9f64dcc77653 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=a3f16850...
Author: Juha Heinanen jh@tutpro.com Committer: Juha Heinanen jh@tutpro.com Date: Sat May 9 19:14:18 2009 +0300
* Moved lcr module from modules_k to modules and removed it from modules_s.
---
{modules_k => modules}/lcr/Makefile | 0 {modules_k => modules}/lcr/README | 0 {modules_k => modules}/lcr/doc/Makefile | 0 {modules_k => modules}/lcr/doc/lcr.xml | 0 {modules_k => modules}/lcr/doc/lcr_admin.xml | 0 {modules_k => modules}/lcr/hash.c | 0 {modules_k => modules}/lcr/hash.h | 0 {modules_k => modules}/lcr/lcr_mod.c | 0 {modules_k => modules}/lcr/lcr_mod.h | 0 {modules_k => modules}/lcr/mi.c | 0 {modules_k => modules}/lcr/mi.h | 0 modules_s/lcr/Makefile | 17 - modules_s/lcr/README | 259 ------ modules_s/lcr/doc/Makefile | 4 - modules_s/lcr/doc/functions.xml | 17 - modules_s/lcr/doc/lcr.xml | 121 --- modules_s/lcr/doc/params.xml | 235 ------ modules_s/lcr/lcr_mod.c | 1113 -------------------------- modules_s/lcr/lcr_mod.h | 61 -- modules_s/lcr/lcr_rpc.c | 104 --- modules_s/lcr/lcr_rpc.h | 35 - modules_s/lcr/ser-lcr.cfg | 24 - 22 files changed, 0 insertions(+), 1990 deletions(-)
Diff: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commitdiff;h=a3f1...
On May 09, 2009 at 18:15, Juha Heinanen jh@tutpro.com wrote:
Module: sip-router Branch: master Commit: a3f16850cd2a897710cb0a56174e9f64dcc77653 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=a3f16850...
Author: Juha Heinanen jh@tutpro.com Committer: Juha Heinanen jh@tutpro.com Date: Sat May 9 19:14:18 2009 +0300
- Moved lcr module from modules_k to modules and removed it from modules_s.
They should have been merged. Looking only at recent commit logs, you lost from modules_s/lcr: - rpc interface - new db api - possible wrong db init from all the processes (see 8fb14f, 9961e8)
Andrei
Andrei Pelinescu-Onciul writes:
They should have been merged. Looking only at recent commit logs, you lost from modules_s/lcr:
- rpc interface
- new db api
- possible wrong db init from all the processes (see 8fb14f, 9961e8)
i don't understand why. i dig
eg pull
before i started working on this and expected my repo to be up to date.
it seems i'm totally incompetent to work with git.
-- juha
On May 10, 2009 at 11:26, Juha Heinanen jh@tutpro.com wrote:
Andrei Pelinescu-Onciul writes:
They should have been merged. Looking only at recent commit logs, you lost from modules_s/lcr:
- rpc interface
- new db api
- possible wrong db init from all the processes (see 8fb14f, 9961e8)
i don't understand why. i dig
eg pull
before i started working on this and expected my repo to be up to date.
it seems i'm totally incompetent to work with git.
No it doesn't have anything to do with git. I meant modules_s/lcr should have been merged with modules_k/lcr, before modules_s/lcr was remvoed and modules_k/lcr moved into modules/lcr. There were some changes in modules_s/lcr mostly related to external apis and rpc support which are not in modules_k/lcr. Some of these changes might be bug fixes (e.g. the db stuff, I don't know how lcr uses db, but it looks like the k version intializes db connections from all the processes ?). The rpc stuff means that someone used to do sercmd lcr.reload would have now to use something different (but rpc support should be trivial to add, it even was in separate files: lcr_rpc.h and lcr_rpc.c). Also the (s) lcr used the new db api, while (k) lcr uses the old one, so from this point of view it's a step-back (we support 2 versions now, but the old version will be slowly obsoleted).
Andrei
Andrei Pelinescu-Onciul writes:
No it doesn't have anything to do with git. I meant modules_s/lcr should have been merged with modules_k/lcr, before modules_s/lcr was remvoed and modules_k/lcr moved into modules/lcr.
ok, the move then needs to somehow be reverted and we need to have two versions of lcr module: s version that has ser interface stuff and k version that scales.
-- juha
Andrei Pelinescu-Onciul writes:
They should have been merged. Looking only at recent commit logs, you lost from modules_s/lcr:
- rpc interface
- new db api
- possible wrong db init from all the processes (see 8fb14f, 9961e8)
andrei,
thanks for pointing the db init issue. in k lcr module database is only accessed when module is initialized and when a reload command is given via mi interface. i'll try to figure out, how to restrict db init to those processes.
-- juha
On May 10, 2009 at 13:04, Juha Heinanen jh@tutpro.com wrote:
Andrei Pelinescu-Onciul writes:
They should have been merged. Looking only at recent commit logs, you lost from modules_s/lcr:
- rpc interface
- new db api
- possible wrong db init from all the processes (see 8fb14f, 9961e8)
andrei,
thanks for pointing the db init issue. in k lcr module database is only accessed when module is initialized and when a reload command is given via mi interface. i'll try to figure out, how to restrict db init to those processes.
For the module intialization db, you could close the db connections afterwards. You could use either mod_init() or child_init() with rank==PROC_INIT. When we'll add the ser rpc interface to it, things will change though: - we'll need DB for PROC_RPC and PROC_FIFO (the binrpc transport and fifo transport). - we'll need DB for all the tcp and tls ser processes, for the xml transport (ser xmlrpc does not run in a separate process, it reuses ser parser for the HTML requests). This would mean everything except PROC_INT, PROC_MAIN, PROC_TIMER, PROC_TCP_MAIN (or everything with rank >0 + PROC_RPC + PROC_FIFO).
Andrei
Andrei Pelinescu-Onciul writes:
- possible wrong db init from all the processes (see 8fb14f, 9961e8)
k only has these ranks:
#define PROC_MAIN 0 /* Main Kamailio process */ #define PROC_TIMER -1 /* Timer attendant process */ #define PROC_TCP_MAIN -4 /* TCP main process */
whereas sr has these:
#define PROC_MAIN 0 /* Main ser process */ #define PROC_TIMER -1 /* Timer attendant process */ #define PROC_RPC -2 /* RPC type process */ #define PROC_FIFO PROC_RPC /* FIFO attendant process */ #define PROC_TCP_MAIN -4 /* TCP main process */ #define PROC_UNIXSOCK -5 /* Unix socket server */ #define PROC_ATTENDANT -10 /* main "attendant process */ #define PROC_INIT -127 /* special rank, the context is the main ser
which rank should i test in child_init if i want db to be initialized only by process that executes mi commands?
-- juha
On May 10, 2009 at 13:26, Juha Heinanen jh@tutpro.com wrote:
Andrei Pelinescu-Onciul writes:
- possible wrong db init from all the processes (see 8fb14f, 9961e8)
k only has these ranks:
#define PROC_MAIN 0 /* Main Kamailio process */ #define PROC_TIMER -1 /* Timer attendant process */ #define PROC_TCP_MAIN -4 /* TCP main process */
whereas sr has these:
#define PROC_MAIN 0 /* Main ser process */ #define PROC_TIMER -1 /* Timer attendant process */ #define PROC_RPC -2 /* RPC type process */ #define PROC_FIFO PROC_RPC /* FIFO attendant process */ #define PROC_TCP_MAIN -4 /* TCP main process */ #define PROC_UNIXSOCK -5 /* Unix socket server */ #define PROC_ATTENDANT -10 /* main "attendant process */ #define PROC_INIT -127 /* special rank, the context is the main ser
which rank should i test in child_init if i want db to be initialized only by process that executes mi commands?
I don't know :-)
Theoretically it should be PROC_RPC, but I'm not sure the kamailio mi transport modules really work, or need some "porting". A quick grep on mi_xmlrpc showed that fork_process use 100 as rank. I think it should use PROC_RPC (anyway something special, meaning not a positive number).
Daniel?
Andrei
Hello,
On 05/10/2009 01:38 PM, Andrei Pelinescu-Onciul wrote:
On May 10, 2009 at 13:26, Juha Heinanen jh@tutpro.com wrote:
Andrei Pelinescu-Onciul writes:
- possible wrong db init from all the processes (see 8fb14f, 9961e8)
k only has these ranks:
#define PROC_MAIN 0 /* Main Kamailio process */ #define PROC_TIMER -1 /* Timer attendant process */ #define PROC_TCP_MAIN -4 /* TCP main process */
whereas sr has these:
#define PROC_MAIN 0 /* Main ser process */ #define PROC_TIMER -1 /* Timer attendant process */ #define PROC_RPC -2 /* RPC type process */ #define PROC_FIFO PROC_RPC /* FIFO attendant process */ #define PROC_TCP_MAIN -4 /* TCP main process */ #define PROC_UNIXSOCK -5 /* Unix socket server */ #define PROC_ATTENDANT -10 /* main "attendant process */ #define PROC_INIT -127 /* special rank, the context is the main ser
which rank should i test in child_init if i want db to be initialized only by process that executes mi commands?
I don't know :-)
Theoretically it should be PROC_RPC, but I'm not sure the kamailio mi transport modules really work, or need some "porting".
MI works now. I have been tested it a lot with fifo so far.
A quick grep on mi_xmlrpc showed that fork_process use 100 as rank.
It is 100, indeed for fifo. Checking the code, I think has to be PROC_NOCHILDINIT because the MI calls a different child init function that is added in the mi_export_t structure. Therefore module's child init should not be called for MI processes.
Cheers, Daniel
I think it should use PROC_RPC (anyway something special, meaning not a positive number).
Daniel?
Andrei
Daniel-Constantin Mierla writes:
It is 100, indeed for fifo. Checking the code, I think has to be PROC_NOCHILDINIT because the MI calls a different child init function that is added in the mi_export_t structure. Therefore module's child init should not be called for MI processes.
daniel,
indeed, in lcr module i have
static mi_export_t mi_cmds[] = { { MI_LCR_RELOAD, mi_lcr_reload, MI_NO_INPUT_FLAG, 0, mi_child_init }, { MI_LCR_GW_DUMP, mi_lcr_gw_dump, MI_NO_INPUT_FLAG, 0, 0 }, { MI_LCR_LCR_DUMP, mi_lcr_lcr_dump, MI_NO_INPUT_FLAG, 0, 0 }, { 0, 0, 0, 0 ,0} };
and
static int mi_child_init(void) { return lcr_db_init(&db_url); }
also, i lcr module i don't have any other child_init function defined.
my conclusion thus is that lcr module db initialization is exactly as it should be.
-- juha
Hello,
On 05/11/2009 11:50 AM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
It is 100, indeed for fifo. Checking the code, I think has to be PROC_NOCHILDINIT because the MI calls a different child init function that is added in the mi_export_t structure. Therefore module's child init should not be called for MI processes.
daniel,
indeed, in lcr module i have
static mi_export_t mi_cmds[] = { { MI_LCR_RELOAD, mi_lcr_reload, MI_NO_INPUT_FLAG, 0, mi_child_init }, { MI_LCR_GW_DUMP, mi_lcr_gw_dump, MI_NO_INPUT_FLAG, 0, 0 }, { MI_LCR_LCR_DUMP, mi_lcr_lcr_dump, MI_NO_INPUT_FLAG, 0, 0 }, { 0, 0, 0, 0 ,0} };
and
static int mi_child_init(void) { return lcr_db_init(&db_url); }
also, i lcr module i don't have any other child_init function defined.
my conclusion thus is that lcr module db initialization is exactly as it should be.
I have changed that the MI processes are started with PROC_NOCHLDINIT. The init should be now as in K - mi processes call only mi_child_init. Anyhow, probably it was pretty ok before as well -- I tested mi fifo several times without any issue -- now is just safer.
Cheers, Daniel
On 10-05 10:15, Andrei Pelinescu-Onciul wrote:
On May 09, 2009 at 18:15, Juha Heinanen jh@tutpro.com wrote:
Module: sip-router Branch: master Commit: a3f16850cd2a897710cb0a56174e9f64dcc77653 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=a3f16850...
Author: Juha Heinanen jh@tutpro.com Committer: Juha Heinanen jh@tutpro.com Date: Sat May 9 19:14:18 2009 +0300
- Moved lcr module from modules_k to modules and removed it from modules_s.
They should have been merged. Looking only at recent commit logs, you lost from modules_s/lcr:
- rpc interface
- new db api
- possible wrong db init from all the processes (see 8fb14f, 9961e8)
lcr modules do not have to be merged (apart from the changes necessary to make it work with the new core). Juha's version in the kamailio tree is more advanced than what we had, in SER I only kept Juha's original lcr version compilable.
Jan.
On May 11, 2009 at 10:55, Jan Janak jan@iptel.org wrote:
On 10-05 10:15, Andrei Pelinescu-Onciul wrote:
On May 09, 2009 at 18:15, Juha Heinanen jh@tutpro.com wrote:
Module: sip-router Branch: master Commit: a3f16850cd2a897710cb0a56174e9f64dcc77653 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=a3f16850...
Author: Juha Heinanen jh@tutpro.com Committer: Juha Heinanen jh@tutpro.com Date: Sat May 9 19:14:18 2009 +0300
- Moved lcr module from modules_k to modules and removed it from modules_s.
They should have been merged. Looking only at recent commit logs, you lost from modules_s/lcr:
- rpc interface
- new db api
- possible wrong db init from all the processes (see 8fb14f, 9961e8)
lcr modules do not have to be merged (apart from the changes necessary to make it work with the new core). Juha's version in the kamailio tree is more advanced than what we had, in SER I only kept Juha's original lcr version compilable.
We need the rpc interface and maybe the db api. I could add the rpc interface to the k version (it's trivial anyway) and take care of the db init for it.
I don't know how difficult would be to switch it to the new db, but I assume it would be trivial too (since lcr doesn't do any advanced db stuff).
Andrei
On 11-05 11:00, Andrei Pelinescu-Onciul wrote:
On May 11, 2009 at 10:55, Jan Janak jan@iptel.org wrote:
On 10-05 10:15, Andrei Pelinescu-Onciul wrote:
On May 09, 2009 at 18:15, Juha Heinanen jh@tutpro.com wrote:
Module: sip-router Branch: master Commit: a3f16850cd2a897710cb0a56174e9f64dcc77653 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=a3f16850...
Author: Juha Heinanen jh@tutpro.com Committer: Juha Heinanen jh@tutpro.com Date: Sat May 9 19:14:18 2009 +0300
- Moved lcr module from modules_k to modules and removed it from modules_s.
They should have been merged. Looking only at recent commit logs, you lost from modules_s/lcr:
- rpc interface
- new db api
- possible wrong db init from all the processes (see 8fb14f, 9961e8)
lcr modules do not have to be merged (apart from the changes necessary to make it work with the new core). Juha's version in the kamailio tree is more advanced than what we had, in SER I only kept Juha's original lcr version compilable.
We need the rpc interface and maybe the db api. I could add the rpc interface to the k version (it's trivial anyway) and take care of the db init for it.
If you need it then take Juha's version and add rpc equivalents to mi commands on top of his code.
I don't know how difficult would be to switch it to the new db, but I assume it would be trivial too (since lcr doesn't do any advanced db stuff).
It should not be that hard, but it is a lot of manual work. This kind of change is not strictly necessary, thus I'd like to wait with this a bit, until the all the code is more stable and working again.
Jan.
Jan Janak writes:
I don't know how difficult would be to switch it to the new db, but I assume it would be trivial too (since lcr doesn't do any advanced db stuff).
It should not be that hard, but it is a lot of manual work. This kind of change is not strictly necessary, thus I'd like to wait with this a bit, until the all the code is more stable and working again.
i agree with that. even if changing database code would be straightforward in theory, there exist lots of db related statements in the code. changing them would take time and would easily lead to typos.
-- juha
Andrei Pelinescu-Onciul writes:
I don't know how difficult would be to switch it to the new db, but I assume it would be trivial too (since lcr doesn't do any advanced db stuff).
it does use DB_CAP_FETCH, but i don't know if that counts "advanced".
-- juha
Jan Janak writes:
They should have been merged. Looking only at recent commit logs, you lost from modules_s/lcr:
- rpc interface
- new db api
- possible wrong db init from all the processes (see 8fb14f, 9961e8)
lcr modules do not have to be merged (apart from the changes necessary to make it work with the new core). Juha's version in the kamailio tree is more advanced than what we had, in SER I only kept Juha's original lcr version compilable.
jan,
i think rpc interface would need to be added if someone is currently using it with ser lcr module.
by the way, how do you use your rcp interface from python or php?
-- juha
On May 11, 2009 at 12:05, Juha Heinanen jh@tutpro.com wrote:
Jan Janak writes:
They should have been merged. Looking only at recent commit logs, you lost from modules_s/lcr:
- rpc interface
- new db api
- possible wrong db init from all the processes (see 8fb14f, 9961e8)
lcr modules do not have to be merged (apart from the changes necessary to make it work with the new core). Juha's version in the kamailio tree is more advanced than what we had, in SER I only kept Juha's original lcr version compilable.
jan,
i think rpc interface would need to be added if someone is currently using it with ser lcr module.
by the way, how do you use your rcp interface from python or php?
xmlrpc (loadmodule "xmlrpc" from .cfg and then it should work with standard xmlrpc libs). There might a quirk or too (we have docs in sip_router/doc/rpc, but it's only an xml, no auto-generated html or txt and it should be re-organized a little since the docs are from the time we had only xmlrpc and they don't take into account the binary rpc/ctl modules part or the fifo).
Juha, it's ok with you if I add the rpc support to lcr? It would help see what exactly would be needed for a module to support both mi and rpc (for example since in ser modules the rpc interface is part of the module interface we have to register rpc functions in a different way in kamailio modules).
Andrei
Andrei Pelinescu-Onciul writes:
xmlrpc (loadmodule "xmlrpc" from .cfg and then it should work with standard xmlrpc libs).
ok.
Juha, it's ok with you if I add the rpc support to lcr? It would help see what exactly would be needed for a module to support both mi and rpc (for example since in ser modules the rpc interface is part of the module interface we have to register rpc functions in a different way in kamailio modules).
sure, please go ahead.
-- juha
On 11-05 12:05, Juha Heinanen wrote:
Jan Janak writes:
They should have been merged. Looking only at recent commit logs, you lost from modules_s/lcr:
- rpc interface
- new db api
- possible wrong db init from all the processes (see 8fb14f, 9961e8)
lcr modules do not have to be merged (apart from the changes necessary to make it work with the new core). Juha's version in the kamailio tree is more advanced than what we had, in SER I only kept Juha's original lcr version compilable.
jan,
i think rpc interface would need to be added if someone is currently using it with ser lcr module.
OK, how about making the MI function also available through the RPC interface in SER? That should be trivial to do, assuming that you already have the functions exported through the MI interface.
by the way, how do you use your rcp interface from python or php?
Through the xml-rpc interface. There is the xmlrpc module in modules_s which exports all functions registered with the rpc interface as xml-rpc methods. I called those function from python programs directly. I also know that Karel extended serweb (written in php) with xml-rpc so serweb is able to call those functions too.
Jan.
On 10-05 10:15, Andrei Pelinescu-Onciul wrote:
On May 09, 2009 at 18:15, Juha Heinanen jh@tutpro.com wrote:
Module: sip-router Branch: master Commit: a3f16850cd2a897710cb0a56174e9f64dcc77653 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=a3f16850...
Author: Juha Heinanen jh@tutpro.com Committer: Juha Heinanen jh@tutpro.com Date: Sat May 9 19:14:18 2009 +0300
- Moved lcr module from modules_k to modules and removed it from modules_s.
They should have been merged. Looking only at recent commit logs, you lost from modules_s/lcr:
- rpc interface
That's not necessary, the rcp interface was only used to reload the data from the database and kamailio version has this too.
- new db api
Not necessary either, it can work with the old db interface, in case of lcr it does not matter whether we use prepared statements or not because the module works primarily with the memory cache.
- possible wrong db init from all the processes (see 8fb14f, 9961e8)
That's the only thing, imho, that needs to be changed.
Jan.
On May 11, 2009 at 10:59, Jan Janak jan@iptel.org wrote:
On 10-05 10:15, Andrei Pelinescu-Onciul wrote:
On May 09, 2009 at 18:15, Juha Heinanen jh@tutpro.com wrote:
Module: sip-router Branch: master Commit: a3f16850cd2a897710cb0a56174e9f64dcc77653 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=a3f16850...
Author: Juha Heinanen jh@tutpro.com Committer: Juha Heinanen jh@tutpro.com Date: Sat May 9 19:14:18 2009 +0300
- Moved lcr module from modules_k to modules and removed it from modules_s.
They should have been merged. Looking only at recent commit logs, you lost from modules_s/lcr:
- rpc interface
That's not necessary, the rcp interface was only used to reload the data from the database and kamailio version has this too.
From my point of view it is. It's lost functionality when going from ser
version to k version.
- new db api
Not necessary either, it can work with the old db interface, in case of lcr it does not matter whether we use prepared statements or not because the module works primarily with the memory cache.
But isn't it a step backwards? At some point in the future we'll obsolete anyway the old db.
- possible wrong db init from all the processes (see 8fb14f, 9961e8)
That's the only thing, imho, that needs to be changed.
Andrei
On 11-05 11:02, Andrei Pelinescu-Onciul wrote:
Not necessary either, it can work with the old db interface, in case of lcr it does not matter whether we use prepared statements or not because the module works primarily with the memory cache.
But isn't it a step backwards? At some point in the future we'll obsolete anyway the old db.
I think it is not. Juha's version of lcr module is much more advanced than the version we had in ser cvs. Basically, I only kept lcr in ser cvs compilable but I never tested it (even after the db changed) because we did not use the module.
Because Juha is the owner of the code, I want him to adopt the version he is familiar with and when we decide that we continue with migration of kamailio modules to the new db api then I will either send him a patch or provide a migration guide.
Because we do not compromise performance in this particular case, it is fine to stick with the older db api version, to make Juha's life easier (we already have enough changes to adapt to already).
Jan.
Jan Janak writes:
- rpc interface
That's not necessary, the rcp interface was only used to reload the data from the database and kamailio version has this too.
jan,
if some ser user has a management system that updates lcr db tables and then makes rpc call to reload them into memory, then that application would stop working.
- possible wrong db init from all the processes (see 8fb14f, 9961e8)
That's the only thing, imho, that needs to be changed.
as i mailed based on daniel's responce, there is nothing wrong with db init in current k lcr module.
-- juha
-
Andrei Pelinescu-Onciul -
Daniel-Constantin Mierla -
Jan Janak -
jh＠tutpro.com -
Juha Heinanen
-
root＠tutpro.com