[
https://issues.apache.org/jira/browse/ARTEMIS-5571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram updated ARTEMIS-5571:
------------------------------------
Description:
We have a setup with two Java servers which run an embedded Artemis broker (one
primary, one backup) and multiple Java clients.
The servers serv1, serv2 also act as JMS clients. For communication between
servers other IPs/hostnames are used as for client/server communication.
Servers connect among each other via hostnames serv1/serv2 but clients connect
via hostnames serv1a,serv1b,serv2a,serv2b. The hostnames serv1 and serv2 are
unknown on client side.
On client side we use a static list of broker addresses. And in general
everything works fine including failover. The only issue is that on the client
we get these kind of errors (which don't seem to have functional impact):
{noformat}
10.07.2025 03:59:23.561 ERROR 9104 --- [ttmSimulatorCluster] [-netty-threads)]
[ ]o.apache.activemq.artemis.core.client :
AMQ214033: Cannot resolve host java.net.UnknownHostException: The requested
name is valid, but no data of the requested type was found (serv1)
at java.base/java.net.Inet4AddressImpl.lookupAllHostAddr(Native Method)
at
java.base/java.net.Inet4AddressImpl.lookupAllHostAddr(Inet4AddressImpl.java:43)
at
java.base/java.net.InetAddress$PlatformResolver.lookupByName(InetAddress.java:1211)
at
java.base/java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1828)
at
java.base/java.net.InetAddress$NameServiceAddresses.get(InetAddress.java:1139)
at java.base/java.net.InetAddress.getAllByName0(InetAddress.java:1818)
at java.base/java.net.InetAddress.getAllByName(InetAddress.java:1688)
at java.base/java.net.InetAddress.getByName(InetAddress.java:1568)
at
org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector.isSameHostAndPort(NettyConnector.java:1325)
at
org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector.isEquivalent(NettyConnector.java:1304)
at
org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.setBackupConnector(ClientSessionFactoryImpl.java:321)
at
org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.notifyNodeUp(ServerLocatorImpl.java:1565)
at
org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl$SessionFactoryTopologyHandler.notifyNodeUp(ClientSessionFactoryImpl.java:1530)
at
org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQClientProtocolManager$Channel0Handler.notifyTopologyChange(ActiveMQClientProtocolManager.java:538)
at
org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQClientProtocolManager$Channel0Handler.handlePacket(ActiveMQClientProtocolManager.java:493)
at
org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.handlePacket(ChannelImpl.java:854)
at
org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.doBufferReceived(RemotingConnectionImpl.java:408)
at
org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:381)
at
org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl$DelegatingBufferHandler.bufferReceived(ClientSessionFactoryImpl.java:1324)
at
org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:73)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:442)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412)
at
io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:346)
at
io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:318)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412)
at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1519)
at
io.netty.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1377)
at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1428)
at
io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:530)
at
io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:469)
at
io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:290)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412)
at
io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1357)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:440)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)
at
io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:868)
at
io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166)
at
io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:796)
at
io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:732)
at
io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:658)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:562)
at
io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:998)
at
io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
at
org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:120){noformat}
In my current understanding the issue is that topology changes are published
with server internal host names. I understand why this happens and I assume we
can in general ignore it because we use a fixed list of server addresses in our
connection url.
I'm just wondering if I can avoid this error to be logged?! I thought I can
avoid it by disabling HA via connection URL parameter (i.e. {{ha=false}}), but
the error still occurs. From the code I can see that in the affected method
{{ServiceLocatorImpl.notifyNodeUp}} the state of HA is not checked where as in
{{ServiceLocatorImpl.notifyNodeDown}} it is handled:
{code:java}
public void notifyNodeDown(final long eventTime, final String nodeID, boolean
disconnect) {
if (!ha) { // there's no topology here return; }{code}
Now I'm wondering if this is intended or a bug and if my general understanding
is correct that disabling HA should avoid {{UnknownHostException}} error.
was:
We have a setup with two Java servers which run an embedded Artemis broker (one
primary, one backup) and multiple Java clients.
The servers serv1, serv2 also act as JMS clients. For communication between
servers other IPs/hostnames are used as for client/server communication.
Servers connect among each other via hostnames serv1/serv2 but clients connect
via hostnames serv1a,serv1b,serv2a,serv2b. The hostnames serv1 and serv2 are
unknown on client side.
On client side we use a static list of broker addresses. And in general
everything works fine including failover. The only issue is that on the client
we get these kind of errors (which don't seem to have functional impact):
{noformat}
10.07.2025 03:59:23.561 ERROR 9104 --- [ttmSimulatorCluster] [-netty-threads)]
[ ]o.apache.activemq.artemis.core.client :
AMQ214033: Cannot resolve host java.net.UnknownHostException: The requested
name is valid, but no data of the requested type was found (serv1)
at java.base/java.net.Inet4AddressImpl.lookupAllHostAddr(Native Method)
at
java.base/java.net.Inet4AddressImpl.lookupAllHostAddr(Inet4AddressImpl.java:43)
at
java.base/java.net.InetAddress$PlatformResolver.lookupByName(InetAddress.java:1211)
at
java.base/java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1828)
at
java.base/java.net.InetAddress$NameServiceAddresses.get(InetAddress.java:1139)
at java.base/java.net.InetAddress.getAllByName0(InetAddress.java:1818)
at java.base/java.net.InetAddress.getAllByName(InetAddress.java:1688)
at java.base/java.net.InetAddress.getByName(InetAddress.java:1568)
at
org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector.isSameHostAndPort(NettyConnector.java:1325)
at
org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector.isEquivalent(NettyConnector.java:1304)
at
org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.setBackupConnector(ClientSessionFactoryImpl.java:321)
at
org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.notifyNodeUp(ServerLocatorImpl.java:1565)
at
org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl$SessionFactoryTopologyHandler.notifyNodeUp(ClientSessionFactoryImpl.java:1530)
at
org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQClientProtocolManager$Channel0Handler.notifyTopologyChange(ActiveMQClientProtocolManager.java:538)
at
org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQClientProtocolManager$Channel0Handler.handlePacket(ActiveMQClientProtocolManager.java:493)
at
org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.handlePacket(ChannelImpl.java:854)
at
org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.doBufferReceived(RemotingConnectionImpl.java:408)
at
org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:381)
at
org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl$DelegatingBufferHandler.bufferReceived(ClientSessionFactoryImpl.java:1324)
at
org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:73)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:442)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412)
at
io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:346)
at
io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:318)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412)
at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1519)
at
io.netty.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1377)
at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1428)
at
io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:530)
at
io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:469)
at
io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:290)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412)
at
io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1357)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:440)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)
at
io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:868)
at
io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166)
at
io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:796)
at
io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:732)
at
io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:658)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:562)
at
io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:998)
at
io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
at
org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:120){noformat}
In my current understanding the issue is that topology changes are published
with server internal host names. I understand why this happens and I assume we
can in general ignore it because we use a fixed list of server addresses in our
connection url.
I'm just wondering if I can avoid this error to be logged?! I thought I can
avoid it by disabling HA via connection URL parameter (?ha=false) but the error
still occurs. From the code I can see that in the affected method
{{ServiceLocatorImpl.notifyNodeUp}} the state of HA is not checked where as in
{{ServiceLocatorImpl.notifyNodeDown}} it is handled:
{code:java}
public void notifyNodeDown(final long eventTime, final String nodeID, boolean
disconnect) {
if (!ha) { // there's no topology here return; }{code}
Now I'm wondering if this is intended or a bug and if my general understanding
is correct that disabling HA should avoid {{UnknownHostException}} error.
> AMQ214033/UnknownHostException on topology changed even if HA disabled
> ----------------------------------------------------------------------
>
> Key: ARTEMIS-5571
> URL: https://issues.apache.org/jira/browse/ARTEMIS-5571
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker, Clustering
> Affects Versions: 2.41.0
> Reporter: Andreas Baumgart
> Priority: Minor
>
> We have a setup with two Java servers which run an embedded Artemis broker
> (one primary, one backup) and multiple Java clients.
> The servers serv1, serv2 also act as JMS clients. For communication between
> servers other IPs/hostnames are used as for client/server communication.
> Servers connect among each other via hostnames serv1/serv2 but clients
> connect via hostnames serv1a,serv1b,serv2a,serv2b. The hostnames serv1 and
> serv2 are unknown on client side.
> On client side we use a static list of broker addresses. And in general
> everything works fine including failover. The only issue is that on the
> client we get these kind of errors (which don't seem to have functional
> impact):
> {noformat}
> 10.07.2025 03:59:23.561 ERROR 9104 --- [ttmSimulatorCluster]
> [-netty-threads)] [
> ]o.apache.activemq.artemis.core.client : AMQ214033: Cannot resolve host
> java.net.UnknownHostException: The requested name is valid, but no data of
> the requested type was found (serv1)
> at java.base/java.net.Inet4AddressImpl.lookupAllHostAddr(Native Method)
> at
> java.base/java.net.Inet4AddressImpl.lookupAllHostAddr(Inet4AddressImpl.java:43)
> at
> java.base/java.net.InetAddress$PlatformResolver.lookupByName(InetAddress.java:1211)
> at
> java.base/java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1828)
> at
> java.base/java.net.InetAddress$NameServiceAddresses.get(InetAddress.java:1139)
> at java.base/java.net.InetAddress.getAllByName0(InetAddress.java:1818)
> at java.base/java.net.InetAddress.getAllByName(InetAddress.java:1688)
> at java.base/java.net.InetAddress.getByName(InetAddress.java:1568)
> at
> org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector.isSameHostAndPort(NettyConnector.java:1325)
> at
> org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector.isEquivalent(NettyConnector.java:1304)
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.setBackupConnector(ClientSessionFactoryImpl.java:321)
> at
> org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.notifyNodeUp(ServerLocatorImpl.java:1565)
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl$SessionFactoryTopologyHandler.notifyNodeUp(ClientSessionFactoryImpl.java:1530)
> at
> org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQClientProtocolManager$Channel0Handler.notifyTopologyChange(ActiveMQClientProtocolManager.java:538)
> at
> org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQClientProtocolManager$Channel0Handler.handlePacket(ActiveMQClientProtocolManager.java:493)
> at
> org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.handlePacket(ChannelImpl.java:854)
> at
> org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.doBufferReceived(RemotingConnectionImpl.java:408)
> at
> org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:381)
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl$DelegatingBufferHandler.bufferReceived(ClientSessionFactoryImpl.java:1324)
> at
> org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:73)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:442)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412)
> at
> io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:346)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:318)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412)
> at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1519)
> at
> io.netty.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1377)
> at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1428)
> at
> io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:530)
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:469)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:290)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1357)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:440)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:868)
> at
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:796)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:732)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:658)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:562)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:998)
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:120){noformat}
> In my current understanding the issue is that topology changes are published
> with server internal host names. I understand why this happens and I assume
> we can in general ignore it because we use a fixed list of server addresses
> in our connection url.
> I'm just wondering if I can avoid this error to be logged?! I thought I can
> avoid it by disabling HA via connection URL parameter (i.e. {{ha=false}}),
> but the error still occurs. From the code I can see that in the affected
> method {{ServiceLocatorImpl.notifyNodeUp}} the state of HA is not checked
> where as in {{ServiceLocatorImpl.notifyNodeDown}} it is handled:
> {code:java}
> public void notifyNodeDown(final long eventTime, final String nodeID, boolean
> disconnect) {
> if (!ha) { // there's no topology here return; }{code}
> Now I'm wondering if this is intended or a bug and if my general
> understanding is correct that disabling HA should avoid
> {{UnknownHostException}} error.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
