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
