Grpc-java: 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 [e-mail]
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
https://github.com/grpc/grpc-java/issues/6954#issuecomment-621369835,
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 [e-mail]
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
https://github.com/grpc/grpc-java/issues/6954#issuecomment-621952952,
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:

https://github.com/grpc/grpc-java/blob/6a50a63ca8ab8e59b0c90a5c6940fde1c063f5c2/netty/src/main/java/io/grpc/netty/NettyChannelBuilder.java#L102-L105

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!