[SR-Users] dmq_t_replicate fails with ERROR: t_forward_nonack: no branches for forwarding

[Leonardo Arena]

On mer, 2015-02-04 at 21:15 +0000, Charles Chance wrote:
> Hi,
> 
> On 3 Feb 2015 10:07, "Leonardo Arena" <rnalrd at gmail.com> wrote:
> >
> > On lun, 2015-02-02 at 17:54 +0000, Charles Chance wrote:

> > [snip ]
> >
> >dmq.my.domain.netresolves to 10.0.0.2 which is proxy2. What I'm
> > effectively trying to do with DNS is to avoid having a static entry
> in
> > configuration file as notification address. I'd like to build a
> dynamic
> > list of notification servers via SRV records and have DMQ honor the
> > priority and weight of such list.
> >
> >
> 
> This will not work currently but I may have some time soon to look
> into it. Unless someone else proposes a patch first.
> 

Yeah, this was my conclusion too after few tests. An SRV query is
actually sent (but only if there's an A record for the the given
notification address), the higher priority address is chosen, but if
this fails it never failover to a lower priority address.

Also if notification server goes down, I haven't seen any attempt to
re-contacting it in case it goes back on-line. Or may be I didn't wait
enough time to observe it.

I think it would be nice to have the information of notification servers
in DNS SRV records. This would help in building a distributed
infrastructure, rather than having such info in static configuration
files, which are more suitable for clusters.

> > >
> > >
> > > I will try to replicate your scenario and come back with a
> solution
> > > shortly.
> > >
> > >
> 
> I have a patch which is working in my tests but I am waiting to hear
> of any possible side effects. It should be in master branch shortly.

I saw the patch on sr-dev. Thanks!

- leonardo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20150205/cddc5004/attachment.sig>