* Pavel Rappo:
>> On 4 Sep 2019, at 17:35, Florian Weimer <fwei...@redhat.com> wrote:
>>
>> * Milan Mimica:
>>
>>> Continuing in a new thread with a RFR of my own:
>>> http://cr.openjdk.java.net/~mmimica/8228580/webrev.00/
>>
>> I would add a comment why there's no explicit TCP connection timeout in
>> the code. I assume you rely on the TCP stack having its own timeout,
>> right? But I think it can be quite long under some circumstances.
>
> If I get this right, there's a default timeout of 1,000 ms (1 second)
> on L70
> src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DnsContext.java
> which applies to the case where there's no explicit timeout. I agree
> though that this deserves a comment.
Maybe I'm mistaken, but I think this:
692 Tcp(InetAddress server, int port, int timeout) throws IOException {
693 sock = new Socket(server, port);
694 sock.setTcpNoDelay(true);
695 out = new java.io.BufferedOutputStream(sock.getOutputStream());
696 in = new java.io.BufferedInputStream(sock.getInputStream());
697 timeoutLeft = timeout;
698 }
creates the TCP socket and connects it. This is a potentially blocking
operation as well. It would make sense to align the timeout for that
with what typical TCP stacks do for SYN segment retransmission.
Different TCP stacks have different connection timeouts, ranging from 70
to 130 seconds or even longer. So the defaults are much larger than
typical DNS timeouts. (Coincidentally, I'm working on fixing the glibc
stub resolver, and I've decided to use a non-blocking connect there
because of the long default timeouts.)
I agree on the matter of clock warp issues. UDP needs fixing too, but
not in this change.
Thanks,
Florian
