Hello Bob, As previously stated, it is a needed improvement.
My time is heavily consumed right now, so your patch will be gratefully received. My only comment would be that once connected to the cluster, notifications are sent to all nodes anyway, not just the one specified in the notification address parameter. So practically, the only need for resolving multiple records is on start-up to find the first available node. Upon contact with that node, a list of the other nodes is returned, all of which are stored and included in subsequent notifications - this is fairly fault-tolerant, providing your network is well designed. It is not tolerant of network splits etc, where it could be possible to end up with two or more separated clusters or split-brain type situations. However, to overcome that, I think we're looking at a *major* redesign - far more than can be achieved with multiple notification addresses. We'd also likely need to consider quorum, voting a primary/master etc. to do it properly. Otherwise, it is a welcome addition in my opinion. Cheers, Charles On 5 March 2015 at 21:41, Robert Boisvert <rdboisv...@gmail.com> wrote: > DMQ Developers, > > Our team would like to setup a DMQ bus > <http://kamailio.org/docs/modules/4.2.x/modules/dmq.html#idp2640048> that > contains more than one notification address > <http://kamailio.org/docs/modules/4.2.x/modules/dmq.html#dmq.p.notification_address> > to support a high availability, fault-tolerant system where multiple > servers are used to maintain the list of DMQ nodes. The failure of any one > DMQ node or the startup order should not cause the DMQ bus to lose track of > available nodes. As nodes go offline and online the DMQ bus should be > updated using information from the active nodes. To do this we propose > changing the way DMQ uses the notification address. > > Currently the notification address resolves a DNS name to a single IP > address even if a SRV record or multiple A/AAAA records are available. The > proposal is to use all the A/AAAA records or SRV targets returned from a > DNS name query as notification addresses. > > Do you have any comments, concerns, suggestions, or recommendations > regarding this proposal? Your input is definitely welcome. > > Thank you, > Bob > > _______________________________________________ > sr-dev mailing list > sr-dev@lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev > > -- www.sipcentric.com Follow us on twitter @sipcentric <http://twitter.com/sipcentric> Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered office: Faraday Wharf, Innovation Birmingham Campus, Holt Street, Birmingham Science Park, Birmingham B7 4BB.
_______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev