On Mon, 7 Nov 2022 15:39:55 GMT, Aleksei Efimov <aefi...@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
