1 Dec
2021
1 Dec
'21
12:36 a.m.
Hi Carsten, likewise on everything you said !
Good questions, a transaction is used and there will be retransmissions.
In such a case we get the normal transaction retransmission mechanism, if a
node becomes disconnected for a while, it is possible to request a full
sync, from all the other nodes, not very efficient but good for
consistency, a restart will do that.
This is why I added batching, on a LAN with support for jumbo frame this
makes a huge difference. (far less transactions, who can be expensive).
Even with an MTU of 1400 this will reduce the amount of transactions
greatly.
There can be race conditions when we sync/replicate while a
registration/unregistration is in progress (something highlighted by
Torrey) at Kamailio world.
Search the mailing list for "DMQ re-ordering concern", we did raise the
concern if any real significant concern there is in the mailing list.
Let us know what you think.
I think we should iterate and improve/deal with race condition concerns,
this native replication protocol is great IMHO
On Tue, Nov 30, 2021 at 1:31 AM Carsten Bock <carsten(a)ng-voice.com> wrote:
Hi Julien,
thanks for your reply - I really appreciate your feedback and your
presentations at KamailioWorld, I hope to see you again in person soon.
Can you share some details on how many records you synchronize using DMQ
and if you ever experienced any loss of records while synchronization using
DMQ? The issue is, that on IMS the registration is typically set to 600000
seconds (1 week), as we have other mechanisms to get notified if a user is
dropping out of the network (we get notifications from the LTE network
itself) and a loss of registration data would result in a user not being
reachable for a long period of time.
Thanks,
Carsten
--
Carsten Bock I CTO & Founder
ng-voice GmbH
Trostbrücke 1 I 20457 Hamburg I Germany
T +49 179 2021244 I www.ng-voice.com
Registry Office at Local Court Hamburg, HRB 120189
Managing Directors: Dr. David Bachmann, Carsten Bock
Am Mo., 29. Nov. 2021 um 18:09 Uhr schrieb Julien Chavanton <
jchavanton(a)gmail.com>gt;:
Hi Carsten, from my experience Usrloc + DMQ works
very well, rare
replication race conditions are insignificant since the state is quite
volatile anyway.
However you can only have that many nodes, great for clustering.
On Mon, Nov 29, 2021 at 6:47 AM Carsten Bock <carsten(a)ng-voice.com>
wrote:
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
* sr-users(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to
the sender!
Edit mailing list options or unsubscribe:
* https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Hi,
I wanted to quickly ask the group about experiences with DMQ and
Usrloc/Dialog.
I don't expect any issues when choosing such an approach, especially
since we would have re-transmits for a message (fr_timer = 30 seconds) if
we did not receive any answers or scenarios alike. So I assume, having
short "outages" (less than 30 seconds) for the communication is just fine.
So far I used DMQ in a non-IMS setup for synchronizing usrloc with ~15k
Subscribers and it worked really well.
One concern brought up (not by me) was, that synchronizing usrloc with
DMQ might not be reliable at scale. I would also love to understand how to
treat situations when the communication is lost for a longer period of time
(e.g. if the communication between nodes is lost for 5 minutes?).
Can anyone share some real-life experiences?
Thanks,
Carsten
--
Carsten Bock I CTO & Founder
ng-voice GmbH
Trostbrücke 1 I 20457 Hamburg I Germany
T +49 179 2021244 I www.ng-voice.com
Registry Office at Local Court Hamburg, HRB 120189
Managing Directors: Dr. David Bachmann, Carsten Bock
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
* sr-users(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to
the sender!
Edit mailing list options or unsubscribe:
* https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
* sr-users(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to
the sender!
Edit mailing list options or unsubscribe:
* https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users