Hi Florian On Mon, 9 Sep 2019 at 15:04, Florian Weimer <fwei...@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
