[OpenSIPS-Devel] [opensips] issue about "usrloc expiring location record from different registrar after startup" (#601)

hd16861686 notifications at github.com
Fri Aug 14 10:17:20 CEST 2015


Hello, how are you?
I got the followed mail from below link, 
http://article.gmane.org/gmane.comp.voip.opensips.user/8242/match=database+synchronization+delete+wrong+contact
But I don't understand why non db-only modes don't support location table sharing. 
I met the same scene issue as described in below mail but in Write-Back scheme of db-mode.
According to "it is only written (cache flushed into DB) and never read (only at startup) ", actually we can read location table through avp_db_query in script in non db-only modes, and the only issue is when opensips 1 restart and load all online user from location table and after a while opensips 1 find some users expired which is regisgtered in opensips 2, but then opensips 1 delete these users even these users is not belong to opensips 1, that's the issue. 
But I think this issue can be solved by modifying the code.
for example in opensips 2.1  in wb_timer function of usrloc module,  the deleting user from db logic below, besides the condition "st_expired_ucontact(t) == 1", we can also add one more condition like "t->sock != 0", so that those expired users not belong to opensips node will not be deleted from db and the issue solved.  

Is this right ? or if i missing something?

                         /* Should we remove the contact from the database ? */
			if (st_expired_ucontact(t) == 1) {
				if (db_delete_ucontact(t) < 0) {
					LM_ERR("failed to delete contact from the database\n");
					/* do not delete from memory now - if we do, we'll get
					 * a stuck record in DB. Future registrations will not be
					 * able to get inserted due to index collision */
					continue;
				}
			}



From: Bogdan-Andrei Iancu <bogdan at ...>
Subject: Re: usrloc expiring location record from different registrar after startup
Newsgroups: gmane.comp.voip.opensips.user
Date: 2009-12-02 09:44:47 GMT (5 years, 36 weeks, 2 days, 15 hours and 6 minutes ago)
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
-- 
Bogdan-Andrei Iancu
www.voice-system.ro

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/issues/601
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20150814/375c3240/attachment-0001.htm>


More information about the Devel mailing list