RFR: 8290714: Make com.sun.jndi.dns.DnsClient virtual threads friendly [v2]

[Daniel Fuchs]

On Mon, 7 Nov 2022 15:39:55 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DnsClient.java line 470:
>> 
>>> 468:                 } while (timeoutLeft > MIN_TIMEOUT);
>>> 469:                 // no matching packet received within the timeout
>>> 470:                 throw new SocketTimeoutException();
>> 
>> It appears to me that, before the change in this PR, we used to return `null` from this method if there is a timeout. The calling code (the method `query`) would then interpret this `null` return in a couple of different ways. One of them being, skipping this server and querying any other server(s) that were known to the client instance. Now, with this change where we throw this `SocketTimeoutException`, that part of the code would behave differently from what I can see. Is this intentional to throw an exception instead of returning `null`?
>
> Thanks for spotting that, Jai.
> You're correct that in its current version the fix changed an old logic of `doUdpQuery`/`query` methods:
> Before this change the method was returning `null` not when a receive is timed out but when an unmatched packet is received. Socket timeout exceptions thrown by `DatagramSocket.receive` were caught in `query` method.
> After the proposed change the `doUdpQuery` method is throwing `SocketTimeoutException` for both cases (timeout and unmatched packets) - that needs to be changed to comply with old logic. Will address it in an upcoming changeset.

This is addressed now - right?

-------------

PR: https://git.openjdk.org/jdk/pull/11007