i started to wonder why routing was sometimes wrong in my proxy and after studying the issue, i came to the conclusion that mtree reload commands (mi or rpc) don't remove entries from memory when they are removed from database.
i started my proxy with empty mtrees db table (and empty memory table):
# sip-proxy_ctl mi mt_summary MT:: TNAME=lp_out TTYPE=0 MEMSIZE=0 NRNODES=0 NRITEMS=0 RELOADCOUNT=0 RELOADTIME=1400419785
then i added one entry to db table and gave reload command. after that one entry correctly showed up in memory table:
# sip-proxy_ctl mi mt_summary MT:: TNAME=lp_out TTYPE=0 MEMSIZE=1636 NRNODES=6 NRITEMS=1 RELOADCOUNT=1 RELOADTIME=1400419817
then i deleted the only entry from db, verified with phpmyadmin that the table really was empty, and gave again reload command. that command didn't have any effect in memory table:
# sip-proxy_ctl mi mt_summary MT:: TNAME=lp_out TTYPE=0 MEMSIZE=1636 NRNODES=6 NRITEMS=1 RELOADCOUNT=1 RELOADTIME=1400419817
not even reload count got incremented.
after that i went and added some debug to rpc_mtree_reload function and got this:
May 18 16:30:17 siika /usr/sbin/sip-proxy[26536]: INFO: mtree [mtree_mod.c:1169]: rpc_mtree_reload(): reloading from db 'lp_out'
the info is here:
LM_INFO("reloading from db '%.*s'\n", pt->tname.len, pt->tname.s); if(mt_load_db(pt)!=0) { LM_ERR("cannot re-load mtree from database\n"); goto error; }
my conclusion is that mt_load_db() function is somehow broken.
-- juha
I guess you are talking about master/development branch, isn't it?
Cheers, Daniel
On 18/05/14 15:41, Juha Heinanen wrote:
i started to wonder why routing was sometimes wrong in my proxy and after studying the issue, i came to the conclusion that mtree reload commands (mi or rpc) don't remove entries from memory when they are removed from database.
i started my proxy with empty mtrees db table (and empty memory table):
# sip-proxy_ctl mi mt_summary MT:: TNAME=lp_out TTYPE=0 MEMSIZE=0 NRNODES=0 NRITEMS=0 RELOADCOUNT=0 RELOADTIME=1400419785
then i added one entry to db table and gave reload command. after that one entry correctly showed up in memory table:
# sip-proxy_ctl mi mt_summary MT:: TNAME=lp_out TTYPE=0 MEMSIZE=1636 NRNODES=6 NRITEMS=1 RELOADCOUNT=1 RELOADTIME=1400419817
then i deleted the only entry from db, verified with phpmyadmin that the table really was empty, and gave again reload command. that command didn't have any effect in memory table:
# sip-proxy_ctl mi mt_summary MT:: TNAME=lp_out TTYPE=0 MEMSIZE=1636 NRNODES=6 NRITEMS=1 RELOADCOUNT=1 RELOADTIME=1400419817
not even reload count got incremented.
after that i went and added some debug to rpc_mtree_reload function and got this:
May 18 16:30:17 siika /usr/sbin/sip-proxy[26536]: INFO: mtree [mtree_mod.c:1169]: rpc_mtree_reload(): reloading from db 'lp_out'
the info is here:
LM_INFO("reloading from db '%.*s'\n", pt->tname.len, pt->tname.s); if(mt_load_db(pt)!=0) { LM_ERR("cannot re-load mtree from database\n"); goto error; }
my conclusion is that mt_load_db() function is somehow broken.
-- juha
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
On 18/05/14 17:14, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
I guess you are talking about master/development branch, isn't it?
sorry, yes, i should have used sr-dev list.
Not big deal at the end, but version is important to know for investigating.
Cheers, Daniel
Looking at the code, if there is no record in the database table corresponding to mtree, the old one is not dismissed, indeed.
I will come with a patch very soon.
Cheers, Daniel
On 18/05/14 17:17, Daniel-Constantin Mierla wrote:
On 18/05/14 17:14, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
I guess you are talking about master/development branch, isn't it?
sorry, yes, i should have used sr-dev list.
Not big deal at the end, but version is important to know for investigating.
Cheers, Daniel
Can you try with code after next commit?
- http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=c36f326d...
Cheers, Daniel
On 18/05/14 18:36, Daniel-Constantin Mierla wrote:
Looking at the code, if there is no record in the database table corresponding to mtree, the old one is not dismissed, indeed.
I will come with a patch very soon.
Cheers, Daniel
On 18/05/14 17:17, Daniel-Constantin Mierla wrote:
On 18/05/14 17:14, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
I guess you are talking about master/development branch, isn't it?
sorry, yes, i should have used sr-dev list.
Not big deal at the end, but version is important to know for investigating.
Cheers, Daniel