[OpenSIPS-Users] usrloc expiring location record from different registrar after startup

Henk Hesselink opensips-users at voipro.nl
Wed Dec 2 12:06:12 CET 2009


Hi Bogdan,

Thanks for clearing that up.  I'll let you know if we still see the
issue with db-only mode.

Regards,

Henk


Bogdan-Andrei Iancu wrote:
> Hi Henk,
>
> In non db-only modes, the primary storage is the mem cache - the DB is
> used only as a secondary storage support (for persistence across
> reboots) and it is only written (cache flushed into DB) and never read
> (only at startup) - this is why you cannot share a location table via 2
> servers.
>
> Let me know if you experience the same problem while using the db-only mode.
>
> Regards,
> Bogdan
>
> Henk Hesselink wrote:
>> Hi Bogdan,
>>
>> I think the problem comes from using write-through mode, I'll see if it
>> goes away with db-only.  It wasn't clear to me from the documentation
>> that only db-only mode is supported with a shared DB.
>>
>> Anyway, in case there is more going on, enclosed are the location table
>> entries for the UAC (name testtcp30001, the 'tcp' means nothing - it
>> uses UDP) and the relevant DB queries.  Registrar A is 79.171.196.85,
>> registrar B is 79.171.192.85.  All servers are synchronized with NTP.
>>
>> - After T1 there is a single record
>> - after T2 also
>> - after T3 the record is gone
>>
>> The Tx.db files all have 2 lines: the location table before and after Tx.
>>
>> Regards,
>>
>> Henk
>>
>>
>> Bogdan-Andrei Iancu wrote:
>>> Hi Henk,
>>>
>>> Reviewing your scenario (in db_only mode):
>>>
>>> T1 - registrar A restarts, finds UA registration inserted by registrar B
>>>          with expiry time T3, prints "non-local socket ... ignoring"
>>> message
>>> T2 - UA registers again with registrar B, sets expiry time to *after* T3
>>> T3 - registrar A deletes record for UA
>>>
>>>
>>> please check:
>>> - after T1, you have a single record for user in the location table
>>> (inserted by A)
>>> - after T2, do you have 2 records for the user (with different contacts)
>>> or the existing one is updated ?
>>> - after T3 - I understand all the records for the user are removed,
>>> right ?
>>>
>>> can you make a capture of the sql queries on the mysql server (to see
>>> what queries - location related- are run by each server).
>>>
>>> I'm asking for all this because, following the code, I cannot "see" the
>>> behaviour you describe - maybe I miss something or maybe there is a bug
>>> somewhere.
>>>
>>> Regarding the other db modes, note they do not work (by design) with
>>> shared dbs.
>>>
>>> May be a useless note, but take care to have sync times on both servers
>>> (A and B) !
>>>
>>> Regards,
>>> Bogdan
>>>
>>>
>>> Henk Hesselink wrote:
>>>> Hi Bogdan,
>>>>
>>>> Did you make the patch?
>>>>
>>>> Regards,
>>>>
>>>> Henk
>>>>
>>>>
>>>> Bogdan-Andrei Iancu wrote:
>>>>
>>>>> Hi Henk,
>>>>>
>>>>> Yes, I'm aware of this issue with the db_only mode - I will prepare a
>>>>> fixing patch for monday, so if you could test it, it will be great!
>>>>>
>>>>> Thanks and regards,
>>>>> Bogdan
>>>>>
>>>>> Henk Hesselink wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> We have several OpenSIPS registrars writing to one location table.
>>>>>> When one of the registrars restarts it logs a lot of the following:
>>>>>>
>>>>>> WARNING:usrloc:dbrow2info: non-local socket<udp:XXXX:5060>...ignoring
>>>>>>
>>>>>> which I believe we can ignore.  But it then deletes all those
>>>>>> non-local
>>>>>> entries at the 'expires' time that was in the database at the time of
>>>>>> the restart.  So:
>>>>>>
>>>>>> T1 - registrar A restarts, finds UA registration inserted by
>>>>>> registrar B
>>>>>>          with expiry time T3, prints "non-local socket ...
>>>>>> ignoring" message
>>>>>> T2 - UA registers again with registrar B, sets expiry time to
>>>>>> *after* T3
>>>>>> T3 - registrar A deletes record for UA
>>>>>>
>>>>>> After T3 the registration for UA never reappears because its register
>>>>>> requests cause registrar B to do an update for a non-existent record.
>>>>>> This seems wrong, or am I missing something?
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Henk



More information about the Users mailing list