[sr-dev] [kamailio/kamailio] Load dialogs from db at runtime, without restarting kamailio (#1274)

[Henning Westerholt]

Am Mittwoch, 4. April 2018, 09:52:23 CEST schrieb Daniel-Constantin Mierla:
> I just committed the config (and kemi) function `dlg_db_load_callid(val)`,
> which should load dialog record from database by matching on callid (it
> loads also associated variables).
> 
> While not tested yet given lack of proper environment to simulate such
> scenario (hopefully you can do it), there is still an issue that needs to
> be sorted out. Respectively a high potential of having conflicts for
> internal dialog id. 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.
> 
> 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.

Hello Daniel,

just a quick comment about the option 1), maybe I did not understood it 
correctly. The scheme would only work for two servers, for e.g. three server 
it would overlap sometimes?

Server 1: 1,3,5
Server 2: 2,4,6
Server 3: 3,6,9

If option 1) will not work, I think option 2) would be the best trade-of, 
giving the rather large implementation and testing effort of 3).
 
> 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.
> 
> Most likely I am going to push code for option 1) for now, but it would be
> good to see opinions from other devs, if they would prefer other option or
> propose other variants.

Best regards,

Henning