JEP-353 - Socket.connect now throws NoRouteToHostException as against ConnectException previously

[Jaikiran Pai]

Hello Alan,

On 21/08/21 9:56 pm, Alan Bateman wrote:
> On 21/08/2021 12:40, Jaikiran Pai wrote:
>> I was able to reproduce this on a MacOS. However, the continuous 
>> integration setup project for Quarkus projects runs these tests 
>> against Linux and Windows setups and they have run into this issue at 
>> least on the Linux OS jobs (I will need to go and check if Windows 
>> jobs had failed too). I can get the specific OS versions if 
>> necessary, but I don't think that will be needed (due to the 
>> reproducer I explain below).
>>
>> :
>>
>> From what I see in the output of this program, the resolution of 
>> microprofile.io returns 4 IP addresses. 2 of them are of type IPv4 
>> and 2 are of type IPv6. Across all Java versions, for IPv4 addresses, 
>> the connection attempts fail with the same 
>> "java.net.SocketTimeoutException: Connect timed out". However, for 
>> the IPv6 addresses, in Java 11, the connection attempts fail with 
>> "java.net.ConnectException: No route to host (connect failed)" 
>> whereas in Java 16, 17 and upstream latest, the connection attempts 
>> against the IPv6 addresses fails with 
>> "java.net.NoRouteToHostException: No route to host".
>
> Thanks for the additional information, I think I understand the issue 
> now.
>
> If you extend your test to include a connect without a timeout then 
> you'll see that old and new implementations throw 
> NoRouteToHostException when the underlying error is EHOSTUNREACH "No 
> route to host".

You are right - I tweaked my example to remove the timeout param being 
passed to the connect method and with that change, the exception that 
gets thrown is consistent (NoRouteToHostException) across Java version 
for IPv6 addresses.


> However, for the connect with timeout case on Linux/macOS/Unix the old 
> implementation doesn't correctly handle network errors when they are 
> reported immediately. It throws ConnectException for all errors, 
> including EHOSTUNREACH "No route to host", whereas it should map the 
> error to a specific exception as it does for the untimed case. It's 
> possible that this bug has existed for a long time.
>
> So while there is indeed a behavior change between the old and new 
> implementation for the timed case where the connect fails immediately, 
> I don't think we should attempt to change the new implementation to 
> have this buggy behavior.
>
Thank you for that explanation and yes, what you say makes sense.


> Do you connections to the Apache HTTP client library and the retry 
> code that is looking for specific exceptions? From a distance it seems 
> very fragile and depending on very implementation specific behavior. I 
> wonder if it has ever been tested on Windows or with an untimed connect.

I am not involved in the Apache HTTP client library project. However, I 
will go ahead and open a discussion in their mailing list and bring this 
issue to their attention, so that they can decide how to deal with it.

Thank you for your help and the explanation.

-Jaikiran