On Tue, 2011-12-20 at 16:49 +0100, Jakub Hrozek wrote:
> I'm not sure if it's still time to include this change in 1.7 since we
> froze the strings yesterday, but if not, feel free to postpone to 1.8.
> [PATCH 1/3] Resolver: Introduce a per-request timeout
> In addition to passing a timeout to c-ares (which controls how long
> would c-ares talk to an individual name server), also set up a tevent
> timeout for the whole request.
> The rationale is that the user of the async interface does not know or
> case how many name servers there are and would like to just limit how
> long the whole request could take. This should help in situations where
> the DNS server is very slow or drops packets.
> [PATCH 2/3] Do not touch resolve_service_state in fo_resolve_service_done
> In the fail over code, we correctly used the "server->common" pointer
> memory context for the resolving but then passed a service resolving
> state as a private context.
> If the service resolving request was canceled before the resolving
> request finished, fo_resolve_service_done would access freed memory.
> This was a long-standing bug in the fail over code we never hit because
> the service resolve request could end only when the resolve request
> ended. I hit the bug when I introduced the timeouts in the later patch.
> [PATCH 3/3] Failover: Introduce a per-service timeout
> Changes the semantics of dns_resolver_timeout to be "how long a
> service resolution can take" from "how long a name resolution can
> I think it is better from the point of view of the fail over user.
> Also introduces a new option dns_resolver_op_timeout which controls the
> resolver timeout (which is what dns_resolver_timeout used to do). It is
> intentionally undocumented.
Ack to all three.