[SR-Users] DMQ re-ordering concern

[Julien Chavanton]

I guess, we could simply use tcp with t_relay using only one process in the
module.

On Thu, May 9, 2019, 04:52 Julien Chavanton <jchavanton at gmail.com> wrote:

>
> 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/c3037a6f/attachment.html>