Receiving Unknown Status code on hostname with InetSocketAddres

[emaayan]

What version of gRPC-Java are you using?

version 1.24.2

What is your environment?

Windows 10/2012/2016, Ubuntu 16, openJDK 8.242

What did you expect to see?

Status code unavailable

What did you see instead?

Status code unknown

Steps to reproduce the bug

used :
NettyChannelBuilder.forAddress(new InetSocketAddress(address,443))
where address contains a hostname that does not exists
got back StatusRuntimeExcetpion with cause of UnresolvedAddressException and code Unknown

[emaayan]

request by:
https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/grpc-io/YGq4zfR-zdU/qr1rVi5_AwAJ

[ejona86]

The problem here is the InetSocketAddress is unresolved, which I don't think we'll ever support. forAddress(SocketAddress) is intended for use in cases something "weird" is going on, like you are using Unix Domain Sockets. I strongly encourage you to use the forAddress(String, port) method instead.

The full status returned:

Status{code=UNKNOWN, description=null, cause=java.nio.channels.UnresolvedAddressException
	at io.grpc.netty.shaded.io.netty.channel.epoll.AbstractEpollChannel.checkResolvable(AbstractEpollChannel.java:336)
	at io.grpc.netty.shaded.io.netty.channel.epoll.AbstractEpollChannel.doConnect(AbstractEpollChannel.java:706)
	at io.grpc.netty.shaded.io.netty.channel.epoll.AbstractEpollChannel$AbstractEpollUnsafe.connect(AbstractEpollChannel.java:562)
	at io.grpc.netty.shaded.io.netty.channel.DefaultChannelPipeline$HeadContext.connect(DefaultChannelPipeline.java:1342)
	at io.grpc.netty.shaded.io.netty.channel.AbstractChannelHandlerContext.invokeConnect(AbstractChannelHandlerContext.java:548)
	at io.grpc.netty.shaded.io.netty.channel.AbstractChannelHandlerContext.connect(AbstractChannelHandlerContext.java:533)
	at io.grpc.netty.shaded.io.netty.channel.ChannelDuplexHandler.connect(ChannelDuplexHandler.java:54)
	at io.grpc.netty.shaded.io.grpc.netty.WriteBufferingAndExceptionHandler.connect(WriteBufferingAndExceptionHandler.java:150)
	at io.grpc.netty.shaded.io.netty.channel.AbstractChannelHandlerContext.invokeConnect(AbstractChannelHandlerContext.java:548)
	at io.grpc.netty.shaded.io.netty.channel.AbstractChannelHandlerContext.access$1000(AbstractChannelHandlerContext.java:61)
	at io.grpc.netty.shaded.io.netty.channel.AbstractChannelHandlerContext$9.run(AbstractChannelHandlerContext.java:538)
	at io.grpc.netty.shaded.io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:164)
	at io.grpc.netty.shaded.io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:472)
	at io.grpc.netty.shaded.io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:384)
	at io.grpc.netty.shaded.io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
	at io.grpc.netty.shaded.io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
	at io.grpc.netty.shaded.io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
	at java.lang.Thread.run(Thread.java:748)

Looks like we should just special-case the exception in Utils.statusFromThrowable.

[emaayan]

then you should at least document it

…

On Wed, Apr 29, 2020 at 8:59 PM Eric Anderson ***@***.***> wrote: The problem here is the InetSocketAddress is unresolved, which I don't think we'll ever support. forAddress(SocketAddress) is intended for use in cases something "weird" is going on, like you are using Unix Domain Sockets. I *strongly* encourage you to use the forAddress(String, port) method instead. The full status returned: Status{code=UNKNOWN, description=null, cause=java.nio.channels.UnresolvedAddressException at io.grpc.netty.shaded.io.netty.channel.epoll.AbstractEpollChannel.checkResolvable(AbstractEpollChannel.java:336) at io.grpc.netty.shaded.io.netty.channel.epoll.AbstractEpollChannel.doConnect(AbstractEpollChannel.java:706) at io.grpc.netty.shaded.io.netty.channel.epoll.AbstractEpollChannel$AbstractEpollUnsafe.connect(AbstractEpollChannel.java:562) at io.grpc.netty.shaded.io.netty.channel.DefaultChannelPipeline$HeadContext.connect(DefaultChannelPipeline.java:1342) at io.grpc.netty.shaded.io.netty.channel.AbstractChannelHandlerContext.invokeConnect(AbstractChannelHandlerContext.java:548) at io.grpc.netty.shaded.io.netty.channel.AbstractChannelHandlerContext.connect(AbstractChannelHandlerContext.java:533) at io.grpc.netty.shaded.io.netty.channel.ChannelDuplexHandler.connect(ChannelDuplexHandler.java:54) at io.grpc.netty.shaded.io.grpc.netty.WriteBufferingAndExceptionHandler.connect(WriteBufferingAndExceptionHandler.java:150) at io.grpc.netty.shaded.io.netty.channel.AbstractChannelHandlerContext.invokeConnect(AbstractChannelHandlerContext.java:548) at io.grpc.netty.shaded.io.netty.channel.AbstractChannelHandlerContext.access$1000(AbstractChannelHandlerContext.java:61) at io.grpc.netty.shaded.io.netty.channel.AbstractChannelHandlerContext$9.run(AbstractChannelHandlerContext.java:538) at io.grpc.netty.shaded.io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:164) at io.grpc.netty.shaded.io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:472) at io.grpc.netty.shaded.io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:384) at io.grpc.netty.shaded.io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989) at io.grpc.netty.shaded.io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) at io.grpc.netty.shaded.io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) at java.lang.Thread.run(Thread.java:748) Looks like we should just special-case the exception in Utils.statusFromThrowable <https://github.com/grpc/grpc-java/blob/d605faafc39d1bf6568a1016364fee5b77c7c02c/netty/src/main/java/io/grpc/netty/Utils.java#L253> . — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#6954 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADGP5MCPQZSWQAI37QBCIVDRPBTH3ANCNFSM4MNOYFPA> .

[ejona86]

Want to send a PR?

FWIW, we do say:

This factory method is primarily intended for using Netty Channel types other than SocketChannel. forAddress(String, int) should generally be preferred over this method, since that API permits delaying DNS lookups and noticing changes to DNS.

We told you "don't use it for this purpose" and we also said it doesn't support "noticing change to DNS." In this case DNS resolution has already been performed and failed, so it will just be permanently broken.

The documentation for InetSocketAddress itself says that unresolved addressed are in a sort of pseudo-broken mode, "If resolution fails then the address is said to be unresolved but can still be used on some circumstances like connecting through a proxy," and gives no guidance for when they may actually work.

I completely agree we should improve the error though to be UNAVAILABLE.

[emaayan]

hmm, this might related to the fact i'm using io.grpc.netty.shaded.io.grpc.netty but my intellij doesn't me any documentation about it i checked my maven .m2 and i the jars containing the javadocs for netty shaded are empty

…

On Thu, Apr 30, 2020 at 7:13 PM Eric Anderson ***@***.***> wrote: Want to send a PR? FWIW, we do say: This factory method is primarily intended for using Netty Channel types other than SocketChannel. forAddress(String, int) should generally be preferred over this method, since that API permits delaying DNS lookups and noticing changes to DNS. We told you "don't use it for this purpose" and we also said it doesn't support "noticing change to DNS." In this case DNS resolution has already been performed and failed, so it will just be permanently broken. The documentation for InetSocketAddress itself says that unresolved addressed are in a sort of pseudo-broken mode, "If resolution fails then the address is said to be unresolved but can still be used on some circumstances like connecting through a proxy," and gives no guidance for when they may actually work. I completely agree we should improve the error though to be UNAVAILABLE. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#6954 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADGP5MHMQTFQ5SCPAS6OYPTRPGPRVANCNFSM4MNOYFPA> .

[ejona86]

Yeah, it is the shading causing the trouble. Javadoc works on source and shading works on class files, so there's no way to let the javadoc process the shaded results.

It's here:

grpc-java/netty/src/main/java/io/grpc/netty/NettyChannelBuilder.java

Lines 102 to 105 in 6a50a63

	* Creates a new builder with the given server address. This factory method is primarily intended
	* for using Netty Channel types other than SocketChannel. {@link #forAddress(String, int)} should
	* generally be preferred over this method, since that API permits delaying DNS lookups and
	* noticing changes to DNS.

Note that "unresolved" only has meaning for InetSocketAddress, so we'd have to say something more like "if you pass an unresolved InetSocketAddress" instead of "if you pass an unresolved socket address".

[reggiemcdonald]

I'm interested in working on this if nobody else wants to?

[ejona86]

@reggiemcdonald, nobody is working on this to my knowledge. Go for it!