[
https://issues.apache.org/jira/browse/ARTEMIS-3676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17491892#comment-17491892
]
Apache Dev commented on ARTEMIS-3676:
-------------------------------------
Yes, already setting "initialConnectAttempts" on client, but even with a high
number of attempts, the error is logged periodically and frequently.
Artemis code is not changed, however I suppose it was Netty exception type
which changed since 2.16.
On Artemis side, I think that the _AnnotatedNoRouteToHostException_ (which
extends _java.net.NoRouteToHostException_) thrown by Netty should be managed in
a similar way to what Artemis does with the _ConnectException_, which is
ignoring the error, as it is in fact a transient connection error, expecially
in a dynamic docker environment.
Thanks
> "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)
