<p>Hello, how are you?<br>
I got the followed mail from below link, <br>
<a href="http://article.gmane.org/gmane.comp.voip.opensips.user/8242/match=database+synchronization+delete+wrong+contact">http://article.gmane.org/gmane.comp.voip.opensips.user/8242/match=database+synchronization+delete+wrong+contact</a><br>
But I don't understand why non db-only modes don't support location table sharing. <br>
I met the same scene issue as described in below mail but in Write-Back scheme of db-mode.<br>
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. <br>
But I think this issue can be solved by modifying the code.<br>
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. </p>
<p>Is this right ? or if i missing something?</p>
<pre><code> /* 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;
}
}
</code></pre>
<p>From: Bogdan-Andrei Iancu <a href="mailto:bogdan@...">bogdan@...</a><br>
Subject: Re: usrloc expiring location record from different registrar after startup<br>
Newsgroups: gmane.comp.voip.opensips.user<br>
Date: 2009-12-02 09:44:47 GMT (5 years, 36 weeks, 2 days, 15 hours and 6 minutes ago)<br>
Hi Henk,</p>
<p>In non db-only modes, the primary storage is the mem cache - the DB is <br>
used only as a secondary storage support (for persistence across <br>
reboots) and it is only written (cache flushed into DB) and never read <br>
(only at startup) - this is why you cannot share a location table via 2 <br>
servers.</p>
<p>Let me know if you experience the same problem while using the db-only mode.</p>
<p>Regards,<br>
Bogdan</p>
<p>Henk Hesselink wrote:</p>
<blockquote>
<p>Hi Bogdan,</p>
<p>I think the problem comes from using write-through mode, I'll see if it<br>
goes away with db-only. It wasn't clear to me from the documentation<br>
that only db-only mode is supported with a shared DB.</p>
<p>Anyway, in case there is more going on, enclosed are the location table<br>
entries for the UAC (name testtcp30001, the 'tcp' means nothing - it<br>
uses UDP) and the relevant DB queries. Registrar A is 79.171.196.85,<br>
registrar B is 79.171.192.85. All servers are synchronized with NTP.</p>
<ul>
<li>After T1 there is a single record</li>
<li>after T2 also</li>
<li>after T3 the record is gone</li>
</ul>
<p>The Tx.db files all have 2 lines: the location table before and after Tx.</p>
<p>Regards,</p>
<p>Henk</p>
<p>Bogdan-Andrei Iancu wrote:</p>
<blockquote>
<p>Hi Henk,</p>
<p>Reviewing your scenario (in db_only mode):</p>
<p>T1 - registrar A restarts, finds UA registration inserted by registrar B<br>
with expiry time T3, prints "non-local socket ... ignoring" <br>
message<br>
T2 - UA registers again with registrar B, sets expiry time to <em>after</em> T3<br>
T3 - registrar A deletes record for UA</p>
<p>please check:</p>
<ul>
<li>after T1, you have a single record for user in the location table
(inserted by A)</li>
<li>after T2, do you have 2 records for the user (with different contacts)
or the existing one is updated ?</li>
<li>after T3 - I understand all the records for the user are removed,
right ?</li>
</ul>
<p>can you make a capture of the sql queries on the mysql server (to see<br>
what queries - location related- are run by each server).</p>
<p>I'm asking for all this because, following the code, I cannot "see" the<br>
behaviour you describe - maybe I miss something or maybe there is a bug<br>
somewhere.</p>
<p>Regarding the other db modes, note they do not work (by design) with<br>
shared dbs.</p>
<p>May be a useless note, but take care to have sync times on both servers<br>
(A and B) !</p>
<p>Regards,<br>
Bogdan</p>
<p>Henk Hesselink wrote:</p>
<blockquote>
<p>Hi Bogdan,</p>
<p>Did you make the patch?</p>
<p>Regards,</p>
<p>Henk</p>
<p>Bogdan-Andrei Iancu wrote:</p>
<blockquote>
<p>Hi Henk,</p>
<p>Yes, I'm aware of this issue with the db_only mode - I will prepare a<br>
fixing patch for monday, so if you could test it, it will be great!</p>
<p>Thanks and regards,<br>
Bogdan</p>
<p>Henk Hesselink wrote:</p>
<blockquote>
<p>Hi all,</p>
<p>We have several OpenSIPS registrars writing to one location table.<br>
When one of the registrars restarts it logs a lot of the following:</p>
<p>WARNING:usrloc:dbrow2info: non-local socketudp:XXXX:5060...ignoring</p>
<p>which I believe we can ignore. But it then deletes all those <br>
non-local<br>
entries at the 'expires' time that was in the database at the time of<br>
the restart. So:</p>
<p>T1 - registrar A restarts, finds UA registration inserted by <br>
registrar B<br>
with expiry time T3, prints "non-local socket ... <br>
ignoring" message<br>
T2 - UA registers again with registrar B, sets expiry time to <br>
<em>after</em> T3<br>
T3 - registrar A deletes record for UA</p>
<p>After T3 the registration for UA never reappears because its register<br>
requests cause registrar B to do an update for a non-existent record.<br>
This seems wrong, or am I missing something?</p>
<p>Thanks,</p>
<h2>Henk</h2>
<p>Bogdan-Andrei Iancu<br>
<a href="http://www.voice-system.ro">www.voice-system.ro</a></p>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br>Reply to this email directly or <a href="https://github.com/OpenSIPS/opensips/issues/601">view it on GitHub</a>.<img alt="" height="1" src="https://github.com/notifications/beacon/AFOciTW4K510xxW6KmEE0MKk5hWbTkRmks5onZuQgaJpZM4Frg9F.gif" width="1" /></p>
<div itemscope itemtype="http://schema.org/EmailMessage">
<div itemprop="action" itemscope itemtype="http://schema.org/ViewAction">
<link itemprop="url" href="https://github.com/OpenSIPS/opensips/issues/601"></link>
<meta itemprop="name" content="View Issue"></meta>
</div>
<meta itemprop="description" content="View this Issue on GitHub"></meta>
</div>