You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@activemq.apache.org by "Apache Dev (Jira)" <ji...@apache.org> on 2022/03/09 09:00:00 UTC

[jira] [Commented] (ARTEMIS-3676) "No route to host" exceptions from Netty

    [ https://issues.apache.org/jira/browse/ARTEMIS-3676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17503405#comment-17503405 ] 

Apache Dev commented on ARTEMIS-3676:
-------------------------------------

Issue seems not to be related to Artemis/Netty versions.
It is a different behaviour between NIO and epoll transports.
With epoll the "no route to host" problem is not logged and connection is retried silently.
But with NIO, logs are full of "no route to host" attempts.


> "No route to host" exceptions from Netty
> ----------------------------------------
>
>                 Key: ARTEMIS-3676
>                 URL: https://issues.apache.org/jira/browse/ARTEMIS-3676
>             Project: ActiveMQ Artemis
>          Issue Type: Bug
>          Components: API
>    Affects Versions: 2.19.1
>            Reporter: Apache Dev
>            Priority: Minor
>
> The following exception is logged when client transport connector is configured with broker hosts currently not available. For example, when configured host is down, which is a situation possible in a container environment:
> {code}
> [2/8/22 15:31:31:678 CET] 00000101 org.apache.activemq.artemis.core.client                      E AMQ214016: Failed to create netty connection
> io.netty.channel.AbstractChannel$AnnotatedNoRouteToHostException: No route to host: activemq2/172.10.0.52:61617
> Caused by: java.net.NoRouteToHostException: No route to host
> 	at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
> 	at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:716)
> 	at io.netty.channel.socket.nio.NioSocketChannel.doFinishConnect(NioSocketChannel.java:330)
> 	at io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.finishConnect(AbstractNioChannel.java:334)
> 	at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:710)
> 	at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:658)
> 	at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:584)
> 	at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:496)
> 	at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:986)
> 	at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> 	at org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
> {code}
>  
> Artemis 2.16 did not log such exceptions (they were handled as transient connection errors).
> Artemis intercepts Netty exception in {{org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector#createConnection(java.util.function.Consumer<io.netty.channel.ChannelFuture>, java.lang.String, int)}}
> and logs it as an error because it is not a ConnectException:
> {code}
>          if (t != null && !(t instanceof ConnectException)) {
>             ActiveMQClientLogger.LOGGER.errorCreatingNettyConnection(future.cause());
>          }
> {code}
> I think it should be handled like a transient connection error, similar to what happens when host machine is up and running but broker is not active.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)