RFR(s): 8228580: DnsClient TCP socket timeout
milan.mimica at gmail.com
Tue Sep 10 14:50:46 UTC 2019
On Mon, 9 Sep 2019 at 15:04, Florian Weimer <fweimer at redhat.com> wrote:
> Ahh. The other option is to stick with one server and keep resending
> with larger and larger timeouts. Switching has the advantage that in
> case of a server problem, you get to a working server more quickly.
> Staying means that if the answer is delayed and you resend exactly the
> same query, you might still pick up the answer to the original query and
> process it, after the first timeout.
Furthermore, the behaviour is documented  and thus can't be just changed.
> But we know that the server is up because it responded our UDP, so
> waiting more than one second for the TCP handshake to succeed might
> worthwhile, yes.
Heh, except the ticket we are trying to solve here is exactly about
the TCP server not being up.
So what do you suggest exactly? Should we set a lower cap? Something
like: Math.max(timeout, 2000 /* or some other value?*/)
The rationale is, if the client requests a initial timeout larger than
1 second (how much larger?) then we can use it as-is. For lower values
(default included) we need to override it to some value that, at the
end of the day, is platform-specific. Sorry, I just don't see how I
can get this right without introducing a bunch of arbitrary constants
to the code.
More information about the core-libs-dev