[SR-Users] DMQ re-ordering concern

[Charles Chance]

Hi Julien,

It's a good point and I agree it could be a concern in some cases.

I'm not sure, however, the DMQ module itself is the place to do it. DMQ is
purely a transport mechanism and has no knowledge or context of what's
being relayed. This limits its scope to the ordering of messages only,
rather than the replicated data.

Limiting DMQ to a single process could have performance implications, and
at the same time does nothing to affect the ordering of messages sent to or
received from multiple nodes (in a cluster of more than two) with varying
distance/latency between them.

The sensible thing to do, in my opinion, is to implement ordering/version
checking within each of the modules that need it. Most of them do anyway,
in some way or another, for messages received locally. It would not be a
big job to extend that to replicated messages and provide some kind of
feedback/reverse-sync to the sending node if the local version is higher or
the timestamp is later.

What do you/others think?

Cheers,

Charles


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

> 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 ...
>>
>>
>> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>


-- 
*Charles Chance*
Managing Director

t. 0330 120 1200    m. 07932 063 891

-- 
Sipcentric Ltd.
                Company registered in England & Wales no. 
7365592. Registered
                office: Faraday Wharf, Innovation 
Birmingham Campus, Holt Street, Birmingham Science Park, Birmingham B7 4BB.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20190509/3f3050a6/attachment.html>