[SR-Users] DMQ re-ordering concern

[Julien Chavanton]

Yesterday at Kamailio World there was an interesting question, raising a
concern about replication of user location and DMQ in general, we should
track it in the mailing list and use it as a feature request and I can
share my initial thoughts on the topic.

The concern was about DMQ reordering transactions.

With SIP registration this seems like a minor concern, high responsiveness
at the cost of potential small inconsistency seems like a good option.
Considering that, the state will automatically correct itself and that this
can be controlled using the expiration timer.  This will become even more
insignificant when the replicas can only be used as primary server
failover. (it becomes a very small concern only when the primary server
fails)

With other type of data re-ordering may result in more problematic use
cases.
My impression is that DMQ should try to be good only with volatile data,
data that will expire anyway, like caching with expiration, registration,
Dialogs, etc.

I think it may be worth looking at adding support for ordering/queuing in
DMQ.

Performance and simplicity could be maintained by doing mainly transactions
in parallel with a configurable re-ordering best effort to minimize the
impact of the problem.

For example :
1- trying to re-order for a configurable amount of time. (32 seconds to
match the RFC for SIP re-transmissions)
2- adding tractability for failed transactions.
3- the possibility to trigger a re-sync.

Another option is to look at preserving strict ordering but I can imagine
this could add more problems in some cases ...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20190509/6a351be6/attachment.html>