22 Aug
2012
22 Aug
'12
3:32 p.m.
Hi,
I upgraded our system to Kamailio 3.3 to take advantage of the new
db_cluster module. Currently we have two registration/location servers
each with their own sql-server. Authenticated REGISTER messages are
forwarded to the other server, which uses the 0x02 flag to save() in
order to store it without generating an extra reply. This works fine.
My goal was to use db_cluster to update both databases at once with save()
and use the failover mode when reading with lookup(). Have anyone tested
a similar setup?
Anyhow, here is how I tried to do it:
modparam("db_cluster","connection","voip1_data2=>postgres://user:pass@hostname1/voipt1_data2")
modparam("db_cluster","connection","voip2_data2=>postgres://user:pass@hostname2/voipt2_data2")
modparam("db_cluster", "cluster",
"data2=>voip1_data2=8s7p;voip2_data2=9s7p")
modparam("usrloc", "db_mode", 2)
modparam("usrloc", "db_url", "cluster://data2")
But I get:
: : <core> [pass_fd.c:293]: ERROR: receive_fd: EOF on 33
: ALERT: <core> [main.c:785]: child process 28275 exited by a signal 11
: ALERT: <core> [main.c:788]: core was generated
: INFO: <core> [main.c:800]: INFO: terminating due to SIGCHLD
Same with db_mode = 1 or 3, and either
modparam("db_cluster", "cluster",
"data2=>voip1_data2=8s9p")
or
modparam("db_cluster", "cluster",
"data2=>voip2_data2=8s9p").
No difference between newly booted phones or phones reregistering.
Backtrace from gdb:
(gdb) bt
#0 0x002fd7da in db_cluster_insert (_h=0xb7d2dc88, _k=0xbf9ac954, _v=0xbf9ac7ec, _n=18)
at dbcl_api.c:334
#1 0x00fbb1cc in db_insert_ucontact (_c=0xb5d828d8) at ucontact.c:565
#2 0x00fcfc5d in insert_ucontact (_r=0xfd3a00, _contact=0xb7d3ce90, _ci=0xc5cc80,
_c=0xbf9acb84) at urecord.c:478
#3 0x00c55bb0 in add_contacts (_m=0xb7d05e40, _d=0xb5d63060, _cflags=0, _uri=0x0) at
save.c:493
#4 save (_m=0xb7d05e40, _d=0xb5d63060, _cflags=0, _uri=0x0) at save.c:864
#5 0x00c4dd43 in w_save2 (_m=0xb7d05e40, _d=0xb5d63060 "00ֵ", _cflags=0x0) at
reg_mod.c:407
#6 0x080586ad in do_action (h=0xbf9acf48, a=0xb7c405c0, msg=0xb7d05e40) at action.c:1157
#7 0x0805fe5c in run_actions (h=0xbf9acf48, a=0xb7c405c0, msg=0xb7d05e40) at
action.c:1644
#8 0x080604e1 in run_actions_safe (h=0xbf9adcb8, a=0xb7c405c0, msg=0xb7d05e40) at
action.c:1708
#9 0x080f96b7 in rval_get_int (h=0xbf9adcb8, msg=0xbf9ac954, i=0xbf9ad268, rv=0xb7c406cc,
cache=0x0) at rvalue.c:920
#10 0x080fcf38 in rval_expr_eval_int (h=0xbf9adcb8, msg=0xb7d05e40, res=0xbf9ad268,
rve=0xb7c406c8) at rvalue.c:1914
#11 0x080fd009 in rval_expr_eval_int (h=0xbf9adcb8, msg=0xb7d05e40, res=0xbf9ad544,
rve=0xb7c40a70) at rvalue.c:1922
#12 0x080585fe in do_action (h=0xbf9adcb8, a=0xb7c41550, msg=0xb7d05e40) at action.c:1121
#13 0x0805fe5c in run_actions (h=0xbf9adcb8, a=0xb7c41550, msg=0xb7d05e40) at
action.c:1644
#14 0x08058657 in do_action (h=0xbf9adcb8, a=0xb7c41650, msg=0xb7d05e40) at action.c:1136
#15 0x0805fe5c in run_actions (h=0xbf9adcb8, a=0xb7c41650, msg=0xb7d05e40) at
action.c:1644
#16 0x0805853d in do_action (h=0xbf9adcb8, a=0xb7bd64d8, msg=0xb7d05e40) at action.c:761
#17 0x0805fe5c in run_actions (h=0xbf9adcb8, a=0xb7bc7128, msg=0xb7d05e40) at
action.c:1644
#18 0x08060464 in run_top_route (a=0xb7bc7128, msg=0xb7d05e40, c=0x0) at action.c:1729
#19 0x080e11e4 in receive_msg (buf=0x82c4f20 "REGISTER sip:hometest.voip.uio.no
SIP/2.0\r\nVia: SIP/2.0/UDP 193.157.149.56;branch=z9hG4bKb8e88f2eE34DCDDD\r\nFrom:
\"kolbutest\"
<sip:2549619@hometest.voip.uio.no>;tag=34CE9BA6-70FCC135\r\nTo:
<sip:2549619@"...,
len=809, rcv_info=0xbf9ade98) at receive.c:209
#20 0x08177f7b in udp_rcv_loop () at udp_server.c:544
#21 0x080b0426 in main_loop () at main.c:1633
#22 0x080b3d02 in main (argc=17, argv=0xbf9ae174) at main.c:2546
Core dumps and debug logs (debug=3) are available.
--
Øyvind Kolbu
University of Oslo