RFR(s): 8228580: DnsClient TCP socket timeout

Milan Mimica milan.mimica at gmail.com
Tue Sep 10 14:50:46 UTC 2019

Hi Florian

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 [1][2] 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.

[1] https://docs.oracle.com/javase/7/docs/technotes/guides/jndi/jndi-dns.html#TIMEOUT
[2] https://bugs.java.com/bugdatabase/view_bug.do?bug_id=4630910

Milan Mimica

More information about the core-libs-dev mailing list