JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown

[Alan Bateman]

On 09/10/2013 19:16, Brian Burkhalter wrote:
> :
> I have created a simple implementation for option B:
>
> http://cr.openjdk.java.net/~bpb/8010371/webrev.3/
>
> I should note that the Unix Inet6 implementation was already using the call ThrowUnknownHostExceptionWithGaiError() to generate the UHE so in this case the message should already have been useful. This call formats the UHE message such as would:
>
> sprintf(error_message, "%s: %s", hostname, gai_strerror(error))
>
> I changed the Unix Inet4 implementation to do this as well instead of calling JNU_ThrowByName().
Thanks for persevering with this, we are on the right road now.

I just looked at JDK-8010371 and the "OS" field is set to "linux". I 
don't know if this is right but as IPv6 is usually enabled by default 
these days then I have to guess that the person that submitted the bug 
has IPv6 disabled or is running with -Djava.net.preferIPv4Stack=true, 
otherwise it would be a non-issue (as you have discovered).

The other thing about your observation is that 
ThrowUnknownHostExceptionWithGaiError is creating the UHE with the both 
the hostname and the error message. This resolves to the concern in one 
or two of the mails that the UHE names the exception message "host" and 
that someone might assume that the exception detail is the hostname.

So thumbs up on the update to src/solaris/native/java/net/Inet4Address.c.

>
> For Windows I added a similar NET_ ThrowUnknownHostExceptionWithGaiError and modified Inet{4,6} to mimic the Unix case. Note that the Windows code has not yet been compiled pending comments.
>
Inet4AddressImpl.lookupAllHostAddr uses gethostbyname and when I look at 
the MSDN documentation then I don't see EAI_AGAIN as possible error. It 
does list WSATRY_AGAIN and I'm wondering if they have the same value and 
whether the WSA* error is only returned by WSAGetLastError?

However I think we have a problem with using gai_strerror here as the 
MSDN documentation says that it is not thread safe. This means we may 
have to look for a WSA equivalent or maybe drop the Windows part of the 
fix (using a mutex of some synchronization might be possible but the 
scope would require research and of course it wouldn't work with 3rd 
party native code that is also using it).

-Alan