[
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)
