This is a different crash to before and is on the receiving node this time.

I have just pushed another fix for this one. Please test again and let me know what happens this time.

Cheers,
Charles

On 28 Aug 2015 07:23, "Kelvin Chua" <kelchy@gmail.com> wrote:
unfortunately it is crashing with current master

i do not see this on my logs

        if (dmq_ul.get_udomain("location", &_d) < 0) {
LM_ERR("Failed to get domain\n");
goto done;
}

here is a backtrace

#0  0x00007f23dc6d92cc in get_urecord (_d=0x0, _aor=0x7ffc8b14cdd0, _r=0x7ffc8b14ce18) at udomain.c:1134
        sl = 32547
        i = 32547
        aorhash = 1712986268
        r = 0x7ffc00000008
#1  0x00007f23dc49d5c8 in add_contact (aor=..., ci=0x7f23dc6ac2c0 <ci>) at usrloc_sync.c:55
        r = 0x7f23dd96f452 <parse_value+371>
        _d = 0x0
        c = 0x7f235390dd93
        contact = {s = 0xb93de0 "", len = -1961570368}
        res = 1402003237
        __FUNCTION__ = "add_contact"
#2  0x00007f23dc4a47e6 in usrloc_dmq_handle_msg (msg=0x7f235390d508, resp=0x7ffc8b14d0a0, node=0x7f2353908410) at usrloc_sync.c:384
        content_length = 403
        body = {
          s = 0x7f235390dd93 "{\"action\":1,\"aor\":\"kelvin\",\"ruid\":\"uloc-55dffbe9-258b-1\",\"c\":\"sip:kelvin@192.168.1.120:5060;alias=4x.1x8.62.213~5060~1\",\"received\":\"\",\"path\":\"<sip:6x.6x.174.22:6055;lr;received=sip:4x.1x8.62.213:5060>"..., len = 403}
        jdoc = {root = 0xb93de0, flags = 0, buf = {
            s = 0x7f235390dd93 "{\"action\":1,\"aor\":\"kelvin\",\"ruid\":\"uloc-55dffbe9-258b-1\",\"c\":\"sip:kelvin@192.168.1.120:5060;alias=4x.1x8.62.213~5060~1\",\"received\":\"\",\"path\":\"<sip:6x.6x.174.22:6055;lr;received=sip:4x.1x8.62.213:5060>"..., len = 403}, malloc_fn = 0x7f23f082a750 <__GI___libc_malloc>, free_fn = 0x7f23f082adf0 <__GI___libc_free>}
        it = 0x0
        ci = {ruid = {s = 0xb92a10 "uloc-55dffbe9-258b-1", len = 20}, c = 0x7ffc8b14cf60, received = {s = 0xb92b60 "", len = 0}, path = 0x7ffc8b14cf80, expires = 1440745337, q = -1, 
          callid = 0x7ffc8b14cf90, cseq = 2, flags = 2, cflags = 0, user_agent = 0x7ffc8b14cfa0, sock = 0x0, methods = 2147483648, instance = {s = 0xba7fe0 "", len = 0}, reg_id = 0, 
          server_id = 0, tcpconn_id = -1, keepalive = 0, xavp = 0x0, last_modified = 1440742397}
        action = 1
        expires = 1440745337
        cseq = 2
        flags = 0
        cflags = 0
        q = -1
        last_modified = 1440742397
        methods = -2147483648
        reg_id = 0
        aor = {s = 0xb92550 "kelvin", len = 6}
        ruid = {s = 0xb92a10 "uloc-55dffbe9-258b-1", len = 20}
        c = {s = 0xb92aa0 "sip:kelvin@192.168.1.120:5060;alias=4x.1x8.62.213~5060~1", len = 56}
        received = {s = 0xb92b60 "", len = 0}
        path = {s = 0xb92bf0 "<sip:6x.6x.174.22:6055;lr;received=sip:4x.1x8.62.213:5060>", len = 58}
        callid = {s = 0xb92cb0 "157459181@192.168.1.120", len = 23}
        user_agent = {s = 0xb92d40 "qutecom/rev-g-trunk", len = 19}
        instance = {s = 0xba7fe0 "", len = 0}
        __FUNCTION__ = "usrloc_dmq_handle_msg"


Kelvin Chua

On Tue, Aug 25, 2015 at 1:27 AM, Charles Chance <charles.chance@sipcentric.com> wrote:
Hi,

I have pushed a change to master which should prevent the crash.

You'll still need (for now) to use "location" in save/lookup - I will add multi-domain replication later but there needs to be some enhancement to the usrloc API first.

Please confirm this fixes the crash and I will backport to 4.3.

Cheers,
Charles


On 18 August 2015 at 06:00, Kelvin Chua <kelchy@gmail.com> wrote:
yes, same crash

Kelvin Chua

On Mon, Aug 17, 2015 at 3:17 PM, Charles Chance <charles.chance@sipcentric.com> wrote:

There were some issues fixed since 4.3.1 - have you tried with latest master?

Cheers,
Charles

On 17 Aug 2015 04:50, "Kelvin Chua" <kelchy@gmail.com> wrote:
i think we should support custom location tables in the future but either way,
i tried changing location to kam_location in 2 instances on usrloc_sync.c -- crash
i tried changing save("location") -- crash


Kelvin Chua

On Fri, Aug 14, 2015 at 7:32 PM, Charles Chance <charles.chance@sipcentric.com> wrote:

Hi,

I'm not sure why, but the dmq_usrloc module was written with the usrloc domain hardcoded as "location".

I intend to address that along with some other improvements but in the meantime, try changing your call to save() to use "location" instead of "kam_location"...

save("location");

Please report back the result.

Cheers,
Charles

On 14 Aug 2015 11:03, "Kelvin Chua" <kelchy@gmail.com> wrote:
4.3.1

kamctl ul show shows blank on the other machine. the registrar is ok.

here is the DMQ message captured using ngrep

Via: SIP/2.0/UDP 1.2.3.4:5080;branch=z9hG4bK97d1.f42de484000000000000000000000000.0.
From: <sip:usrloc@1.2.3.4:5080>;tag=c5ea0db92ae4ac0758f8c2b12d8addf4-4d17.
CSeq: 10 KDMQ.
Content-Length: 403. 
User-Agent: Sipsurge Registrar/1.0.0.
Max-Forwards: 1.
Content-Type: application/json.
.
{"action":1,"aor":"kelvin","ruid":"uloc-55cdbac7-6bd4-1","c":"sip:kelvin@192.168.1.120:5060;alias=2.4.6.8~5060~1","received":"","path":"<sip:1.2.3.4:6055;lr;received=sip:2.4.6.8:5060>","callid":"559751939@192.168.1.120","user_agent":"qutecom/rev-g-trunk","instance":"","expires":1439549023,"cseq":2,"flags":0,"cflags":0,"q":-1,"last_modified":1439546083,"methods":4294967295,"reg_id":0}


here are the modparams

modparam("usrloc", "db_mode", 0)
modparam("usrloc", "use_domain", MULTIDOMAIN)
modparam("dmq", "server_address", DMQ_INT)
modparam("dmq", "notification_address", DMQ_EXT)
modparam("dmq_usrloc", "enable", 1)


sometimes, the registrar crashes, sometimes, the backup, sometimes both but i manage to catch kamctl ul show and this is how it looks like:

Domain:: kam_location table=1024 records=1 max_slot=1
        AOR:: kelvin
                Contact:: sip:kelvin@192.168.1.120:5060;alias=2.4.6.8~5060~1 Q=
                        Expires:: deleted
                        Callid:: 559751939@192.168.1.120
                        Cseq:: 30
                        User-agent:: qutecom/rev-g-trunk
                        Path:: <sip:1.2.3.4:6055;lr;received=sip:2.4.6.8:5060>
                        State:: CS_DIRTY
                        Flags:: 0
                        Cflag:: 0
                        Socket:: udp:1.2.3.4:5080
                        Methods:: 4294967295
                        Ruid:: uloc-55cdbac7-6bd4-1
                        Reg-Id:: 0
                        Last-Keepalive:: 1439546340
                        Last-Modified:: 1439546340


Kelvin Chua

On Thu, Aug 13, 2015 at 7:54 PM, Charles Chance <charles.chance@sipcentric.com> wrote:
Hello,

From which version has this been generated?

Also, can you provide the output of "kamctl ul show" and the relevant modparam sections of your config (usrloc, dmq, dmq_usrloc).

Cheers,
Charles


On 13 August 2015 at 10:23, Kelvin Chua <kelchy@gmail.com> wrote:
I don't know if this is related, this happens on 4.3.1 as well but usrloc crashes once it gets a DMQ

#0  0x00007f2a82a5727c in get_urecord_by_ruid (_d=0x0, _aorhash=8118438, _ruid=0x7ffe6028d5c0, _r=0x7ffe6028d568, _c=0x7ffe6028d578)
    at udomain.c:1153
#1  0x00007f2a8282029a in usrloc_get_all_ucontact (node=0x7f2a01790998) at usrloc_sync.c:166
#2  0x00007f2a828240a7 in usrloc_dmq_handle_msg (msg=0x7f2a01790f78, resp=0x7ffe6028d820, node=0x7f2a01790998) at usrloc_sync.c:363
#3  0x00007f2a83959e6f in worker_loop (id=1) at worker.c:105
#4  0x00007f2a8393e566 in child_init (rank=0) at dmq.c:293
#5  0x0000000000599658 in init_mod_child (m=0x7f2a86955c78, rank=0) at sr_module.c:898
#6  0x0000000000599390 in init_mod_child (m=0x7f2a86956098, rank=0) at sr_module.c:895
#7  0x0000000000599390 in init_mod_child (m=0x7f2a86956a78, rank=0) at sr_module.c:895
#8  0x0000000000599390 in init_mod_child (m=0x7f2a86956e68, rank=0) at sr_module.c:895
#9  0x0000000000599390 in init_mod_child (m=0x7f2a869570f8, rank=0) at sr_module.c:895
#10 0x0000000000599390 in init_mod_child (m=0x7f2a86957498, rank=0) at sr_module.c:895
#11 0x0000000000599390 in init_mod_child (m=0x7f2a86957838, rank=0) at sr_module.c:895
#12 0x0000000000599390 in init_mod_child (m=0x7f2a86957db0, rank=0) at sr_module.c:895
#13 0x0000000000599390 in init_mod_child (m=0x7f2a86958090, rank=0) at sr_module.c:895
#14 0x0000000000599390 in init_mod_child (m=0x7f2a869582c0, rank=0) at sr_module.c:895
#15 0x0000000000599390 in init_mod_child (m=0x7f2a869589b0, rank=0) at sr_module.c:895
#16 0x0000000000599390 in init_mod_child (m=0x7f2a86958f88, rank=0) at sr_module.c:895
#17 0x0000000000599390 in init_mod_child (m=0x7f2a869594d8, rank=0) at sr_module.c:895
#18 0x000000000059996c in init_child (rank=0) at sr_module.c:924
#19 0x00000000004aa753 in main_loop () at main.c:1650
#20 0x00000000004b02b0 in main (argc=13, argv=0x7ffe6028e318) at main.c:2533


Kelvin Chua

On Sat, Aug 8, 2015 at 12:09 AM, Asgaroth <00asgaroth00@gmail.com> wrote:

Hi,

 

Yes, I do see it replicating contacts to the other 2 servers on the dmq bus, however, I did come across a strange issue with the max contacts parameter, which the devs are looking at:

 

https://github.com/kamailio/kamailio/issues/265

 

Cheers

 

 

From: sr-users [mailto:sr-users-bounces@lists.sip-router.org] On Behalf Of Kelvin Chua
Sent: Friday 7 August 2015 14:56
To: Kamailio (SER) - Users Mailing List <sr-users@lists.sip-router.org>
Subject: Re: [SR-Users] dmq_usrloc

 

have you seen your usrloc actually populate data from another server?

i can verify my dmq is working properly. just usrloc not populating.


Kelvin Chua

 

On Fri, Aug 7, 2015 at 6:22 PM, Asgaroth <00asgaroth00@gmail.com> wrote:

Hi,

 

I’m a new user to the dmq subsystem in kamailio, but, once I had a properly configured dmq environment and loaded dmq_usrloc after dmq, all I had to do was add the following to the module paramters:

 

modparam("dmq_usrloc", "enable", 1)

 

Then in the routing logic of the registrar’s you just need to add the appropriate dmq message handling blocks.

 

Hope this helps in some way.

 

 

 

From: sr-users [mailto:sr-users-bounces@lists.sip-router.org] On Behalf Of Kelvin Chua
Sent: Thursday 6 August 2015 07:29
To: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users Mailing List <sr-users@lists.sip-router.org>
Subject: [SR-Users] dmq_usrloc

 

is there any function to trigger replication?

 

i enabled the module and dmq is working for my htables

but usrloc is not replicating.

 

"kamctl ul show" does not show anything

 

i used ngrep to trace the KDMQ packets, i can see the frequent exchanges but nothing related to usrloc. am i doing something wrong?


Kelvin Chua


_______________________________________________
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

 


_______________________________________________
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



_______________________________________________
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




--
Charles Chance
Managing Director

t. 0121 285 4400    m. 07932 063 891

** We're rebranding! Learn more here **

www.sipcentric.com

Follow us on twitter @sipcentric

Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered office: Faraday Wharf, Innovation Birmingham Campus, Holt Street, Birmingham Science Park, Birmingham B7 4BB.
_______________________________________________
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



_______________________________________________
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


** We're rebranding! Learn more here **

www.sipcentric.com

Follow us on twitter @sipcentric

Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered office: Faraday Wharf, Innovation Birmingham Campus, Holt Street, Birmingham Science Park, Birmingham B7 4BB.

_______________________________________________
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



_______________________________________________
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


** We're rebranding! Learn more here **

www.sipcentric.com

Follow us on twitter @sipcentric

Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered office: Faraday Wharf, Innovation Birmingham Campus, Holt Street, Birmingham Science Park, Birmingham B7 4BB.

_______________________________________________
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



_______________________________________________
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




--
Charles Chance
Managing Director

t. 0121 285 4400    m. 07932 063 891

** We're rebranding! Learn more here **

www.sipcentric.com

Follow us on twitter @sipcentric

Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered office: Faraday Wharf, Innovation Birmingham Campus, Holt Street, Birmingham Science Park, Birmingham B7 4BB.

_______________________________________________
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



_______________________________________________
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


** We're rebranding! Learn more here **

www.sipcentric.com

Follow us on twitter @sipcentric

Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered office: Faraday Wharf, Innovation Birmingham Campus, Holt Street, Birmingham Science Park, Birmingham B7 4BB.