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