Hi Team
I'm still hunting down DMQ dialog issues.
https://www.kamailio.org/docs/modules/devel/modules/dialog.html#dialog.p.ena...
Quote: "Notably, it is not possible to send in-dialog requests on any but the original proxy instance."
I make sure, that if a procied call (with same callID) is being redirected from anywhere, it is send to the came dialog aware kamailio instance it originated from. This seems to have fixed a lot of issues with dialogues getting corrupted.
The two main purposed we use dialog is:
* CDR * Channel Counting / Limiting
modparam("dialog", "profiles_with_value", "custprofilecounter");
Can a such profile WITH value be written from any node sharing dialog via DMQ or is this bound to cause troubes?
Example.
Two call get to same customer, but over two different nodes.
Node A is getting a call:
set_dlg_profile("custprofilecounter","Customer7664"); get_profile_size("custprofilecounter","Customer7664","$var(busy_count)");
=> $var(busy_count) is now 1. The profile is replicated to Node B and the value can be accessed there.
While Call on Node A is running, Node B is getting a call to same customer:
set_dlg_profile("custprofilecounter","Customer7664"); get_profile_size("custprofilecounter","Customer7664","$var(busy_count)");
=> $var(busy_count) is now 2 on Node B.
Is this value being replicated BACK to Node A where the profile counter originally was created?
As far as I have experienced, this is the case.
But what happens if the call on Node B is ending before the Call on Node A? Will the counter being decreased also correctly be replicated to Node A?
What happens the other way round?
What happens if both call end at the same time? Is a race condition possible, or is there some sort of locking to prevent this?
Can I use profiles_with_value the way I use them? Or is this bound to fail because it's not supported?
Mit freundlichen Grüssen
-Benoît Panizzon-
Hello,
some installations are using this distributed profile support also with writes from different places. It works ok for the usual application (like channel limiting, fraud mitigation etc..).
There is no locking in place, so if by some reasons a profile value will be updated from two servers the same time, it will probably not be the correct value saved in the profile. But usually this self-recovers, for example in the night due to the (dialog) timeout. If you are concerned with correctness against this kind of race conditions, you should think about using a real distributed datastore, like a clustered SQL/NOSQL database.
Cheers,
Henning
-
Benoit Panizzon -
Henning Westerholt