Hi Aron,
On 06/30/2011 10:40 PM, Aron Rosenberg wrote:
Bogdan and Stan,
On Thu, Jun 30, 2011 at 11:14 AM, Bogdan-Andrei Iancu
<[email protected] <mailto:[email protected]>> wrote:
Hi Stan,
On 06/30/2011 08:48 PM, Stanisław Pitucha wrote:
On 30 June 2011 17:25, Bogdan-Andrei Iancu<[email protected]
<mailto:[email protected]>> 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.
Partially you are right :) - the internal hash is not affected as it is
using the callid also as key (see the match mode in the usrloc module).
But about the DB, you are right - in NATed cases, contacts may overlap.
As fix I suggest adding the callid field in the "unique" key also. This
should cover all the cases (when received or path is used).
Thanks and regards,
Bogdan
--
Bogdan-Andrei Iancu
OpenSIPS eBootcamp - 2nd of May 2011
OpenSIPS solutions and "know-how"
_______________________________________________
Devel mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
