[SR-Users] usrloc module with dbmode=2 does not insert records to database

Daniel-Constantin Mierla miconda at gmail.com
Mon Jan 16 15:27:55 CET 2017


You should not delete the record only from database via a db client
There is a rpc command to delete it, which will take care of removing it
from memory as well as from database (depending on the db_mode module
parameter for usrloc).

Cheers,
Daniel


On 16/01/2017 14:46, Vik Killa wrote:
> The record we added via RPC was first creating a new contact (and
> inserting into the db), this was working fine. But we found that if we
> cleared the database, any "updates" would fail. Adding that parameter
> caused the record to get inserted if an update failed (re-register)
>
>
> On Mon, Jan 16, 2017 at 3:28 AM, Daniel-Constantin Mierla
> <miconda at gmail.com <mailto:miconda at gmail.com>> wrote:
>
>     The record you add via rpc is creating a new contact in memory or
>     it's updating an existing one?
>
>     Can you dump the record after you add it over rpc and send it over
>     to mailing list to see what attributes it has?
>
>     Cheers,
>     Daniel
>
>
>     On 14/01/2017 16:25, Vik Killa wrote:
>>     resolution update -- 
>>     we found that setting 
>>     `modparam("usrloc", "db_check_update", 1)`
>>
>>     fix the issue by inserting missing rows on re-reg
>>
>>     Thanks!
>>
>>
>>     On Fri, Jan 13, 2017 at 9:30 AM, Vik Killa <vipkilla at gmail.com
>>     <mailto:vipkilla at gmail.com>> wrote:
>>
>>         Hi Daniel,
>>         RPC flush is not setting the flag, but im not sure that is
>>         where the issue is, as I stated, we are not setting any
>>         memory-only flags with save()
>>
>>         But here is the flush function (FL_MEM not set)
>>
>>         static void ul_rpc_flush(rpc_t* rpc, void* ctx)
>>         {
>>         synchronize_all_udomains(0, 1);
>>         return;
>>         }
>>
>>         Any ideas?
>>         Thanks,
>>         /V
>>
>>
>>         On Fri, Jan 13, 2017 at 9:24 AM, Vik Killa
>>         <vipkilla at gmail.com <mailto:vipkilla at gmail.com>> wrote:
>>
>>             Hi,
>>             We have tried using these flags:
>>
>>             save("location")
>>             save("location", "0x00")
>>             save("location", "0x04")
>>
>>             And still memory does not get flushed to DB.
>>             I will test the RPC command.
>>             Thanks,
>>             /V
>>
>>
>>             On Fri, Jan 13, 2017 at 9:12 AM, Daniel-Constantin Mierla
>>             <miconda at gmail.com <mailto:miconda at gmail.com>> wrote:
>>
>>                 Hello,
>>
>>                 that flag is used to mark a contact for storage only
>>                 in memory. The save() function has a parameter with
>>                 flags where this kind of storage can be set. Can you
>>                 check the RPC command is setting this flag?
>>
>>                 Cheers,
>>                 Daniel
>>
>>
>>                 On 13/01/2017 15:06, Vik Killa wrote:
>>>                 following up here
>>>                 i found if we comment out a single line of code,
>>>                 kamcmd ul.flush works
>>>
>>>                 here is the git diff
>>>
>>>
>>>
>>>                 diff --git a/src/modules/usrloc/ucontact.c
>>>                 b/src/modules/usrloc/ucontact.c
>>>                 index 47f3c2f..633ca81 100644
>>>                 --- a/src/modules/usrloc/ucontact.c
>>>                 +++ b/src/modules/usrloc/ucontact.c
>>>                 @@ -474,7 +474,7 @@ int
>>>                 db_insert_ucontact(ucontact_t* _c)
>>>                         int nr_cols;
>>>                         
>>>                         if (_c->flags & FL_MEM) {
>>>                 -               return 0;
>>>                 +               //return 0;
>>>                         }
>>>                         if(unlikely(_c->ruid.len<=0)) {
>>>                                 LM_ERR("invalid ruid for aor: %.*s\n",
>>>
>>>
>>>
>>>
>>>
>>>                 I don't quite understand the logic in that code.
>>>                 Does anyone have an idea of why `        if
>>>                 (_c->flags & FL_MEM) {`   returns?
>>>
>>>                 Thanks,
>>>                 /V
>>>
>>>
>>>                 On Thu, Jan 12, 2017 at 4:34 PM, Vik Killa
>>>                 <vipkilla at gmail.com <mailto:vipkilla at gmail.com>> wrote:
>>>
>>>                     Hello,
>>>                     we've noticed that the usrloc module does not
>>>                     "sync" all the records from memory into the
>>>                     database.
>>>                     I use a bash script to generate in-memory AoRs
>>>                     (http://paste.debian.net/plain/908521
>>>                     <http://paste.debian.net/plain/908521>)
>>>                     then i perform
>>>                     kamcmd ul.flush 
>>>                     and no records are inserted.
>>>                     We have tried various usrloc parameters but none
>>>                     seem to work
>>>                     Here is our basic setup
>>>
>>>                     # ----- usrloc params -----
>>>                     modparam("usrloc", "db_url", DBURL)
>>>                     modparam("usrloc", "db_mode", 2)
>>>                     modparam("usrloc", "use_domain", 1)
>>>                     modparam("usrloc", "timer_interval", 120)
>>>                     modparam("usrloc", "timer_procs", 4)
>>>
>>>                     We are using postgresql.
>>>                     are we missing something?
>>>
>>>                     Thanks
>>>                     /V
>>>
>>>
>>>
>>>
>>>                 _______________________________________________
>>>                 SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>>                 sr-users at lists.sip-router.org
>>>                 <mailto:sr-users at lists.sip-router.org>
>>>                 http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>                 <http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users>
>>
>>                 -- 
>>                 Daniel-Constantin Mierla
>>                 www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda
>>                 <http://www.linkedin.com/in/miconda>
>>                 Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com <http://www.kamailioworld.com>
>>
>>                 _______________________________________________ SIP
>>                 Express Router (SER) and Kamailio (OpenSER) -
>>                 sr-users mailing list sr-users at lists.sip-router.org
>>                 <mailto:sr-users at lists.sip-router.org>
>>                 http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>                 <http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users>
>>
>>
>>     _______________________________________________
>>     SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>     sr-users at lists.sip-router.org <mailto:sr-users at lists.sip-router.org>
>>     http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>     <http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users>
>     -- 
>     Daniel-Constantin Mierla
>     www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
>     Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com <http://www.kamailioworld.com>
>
>     _______________________________________________ SIP Express Router
>     (SER) and Kamailio (OpenSER) - sr-users mailing list
>     sr-users at lists.sip-router.org
>     <mailto:sr-users at lists.sip-router.org>
>     http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>     <http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users> 
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- 
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20170116/b1f46b2f/attachment.html>


More information about the sr-users mailing list