[OpenSIPS-Devel] SF.net SVN: opensips:[8105] trunk/modules/usrloc

[Aron Rosenberg]

Bogdan and Stan,

On Thu, Jun 30, 2011 at 11:14 AM, Bogdan-Andrei Iancu
<bogdan at opensips.org>wrote:

> Hi Stan,
>
>
> On 06/30/2011 08:48 PM, Stanisław Pitucha wrote:
>
>> On 30 June 2011 17:25, Bogdan-Andrei Iancu<bogdan at opensips.org>  wrote:
>>
>>> Revision: 8105
>>>          http://opensips.svn.**sourceforge.net/opensips/?rev=**
>>> 8105&view=rev<http://opensips.svn.sourceforge.net/opensips/?rev=8105&view=rev>
>>> Author:   bogdan_iancu
>>> Date:     2011-06-30 16:25:18 +0000 (Thu, 30 Jun 2011)
>>>
>>> Log Message:
>>> -----------
>>> - fixed race between UPDATE and DELETE when using DB_ONLY mode (one
>>> processe can update a record, while timer proc tries to delete it). The
>>> result is loosing contacts from database. The fix is to use REPLACE (if
>>> available on DB level) instead of UPDATE (as records may be missing).
>>>  Based on an original idea from patch #2969454; Credits go to Stanislaw
>>> Pitucha
>>>
>> I think a bit too much stuff was stripped. Now the old db schema is
>> used without any control from the user.
>> That means there's no unique key to generate the conflict
>> (update/replace happens only on key collision) on insert
>>
> Thanks for reminding me on that - I almost forgot to update the DB schema
> and to add the unique key constraint as you mentioned  - just did that
>
>
>   and no way to
>> turn off the "atomic" updates from the config if you want the old
>> schema... Unless it's properly documented in the manual it might cause
>> some really bizarre situations for people using DB_ONLY.
>>
> What kind of side effects are you referring at ? My idea was to try to
> automatically fix the problem (when DB_ONLY is used), transparent for the
> user. Of course, it is not a big deal to add the config switch for that, but
> I don't see why you should disable it and run a buggy code :D.
>
> Thanks and regards,
> Bogdan
>
>
> --
>
> One major issue with enforcing a unique index on username,contact is that
if a client comes in and is using a Path: header, the contact address
is irrelevant and not "fixed up" so two accounts from behind NAT's both on
the 192.168.1.x range will have conflicts resulting in one endpoint being
silently dropped. I believe this is also a problem with the internal hash
table too.

-Aron
Aron Rosenberg
Lifesize / Logitech
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20110630/9695a542/attachment.htm>