Regarding the issue 1274 (https://github.com/kamailio/kamailio/issues/1274)
there's a problem in highly scalable environments to avoid conflicts in storing
dialogs in the same DB.
As @miconda pointed out:
> The internal id is made from two integers, hash entry and hash id (h_entry,
> h_id). h_entry is the index of the slot in the hash table used to store the
> dialog structure, computed by hashing over call id. h_id is an incremented
> integer specific for each hash table slot.
>
> So, when loading a new record from database, if its h_id is not conflicting
> with an existing dialog on the same hash table slot, all is ok, otherwise the
> module is not going to work properly with two dialogs having same h_id.
>
> So, when loading a new record from database, if its h_id is not conflicting
> with an existing dialog on the same hash table slot, all is ok, otherwise the
> module is not going to work properly with two dialogs having same h_id.
>
> Among solutions I thought of:
>
> 1. have the servers generating non conflicting h_id, by having a start value
> different per server and an increment step larger than the number of servers.
> Iirc, here was at some point a similar attempt, but somehow didn't make it.
> Let's say one has two servers, first server starts allocating h_id from 1 and
> increments by 2 (e.g: 1, 3, 5, ...) and the seconds start from 2 and
> increments with 2 (2, 4, 6, ...). Those values can be set via mod params,
> eventually with an option to rely on server_id.
> This should be the least intrusive in the other modules built on top of
> dialog. But it is rather rigid, with the example above, if one adds an extra
> server, it needs to reconfigure the old ones, so each server starts from
> either 1, 2 or 3 and increment by 3. Of course, one can set increment step to
> a larger value, like 100, and then has flexibility to deploy up to 1 hundred
> servers before having to reconfigure in case there is need for more server.
>
> 2. add server_id as the third field in the dialog id. It will require review
> of other modules using dialog and eventual code updates in those modules. One
> column to store the server_id needs to be added to dialog db tables.
>
> 3. switch from this conflicting id system to something like string unique
> ids, similar to what we have in usrloc records. This will require coding in
> other modules, changes to database schema, etc., so more work comparing with
> the above two, but could be the best in long term.
It would be great to have the option 3 developed if possible but we would also
be satisfied with the option 2 to have a third field, server_id, in the dialog
id.
Thank You!
--
Alex
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1500
_______________________________________________
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
