[jboss-jira] [JBoss JIRA] (WFLY-9876) ActiveMQ Artemis with IPv6 and Scope fails
Jens Popp created WFLY-9876:
-------------------------------
Summary: ActiveMQ Artemis with IPv6 and Scope fails
Key: WFLY-9876
URL: https://issues.jboss.org/browse/WFLY-9876
Project: WildFly
Issue Type: Bug
Components: JMS
Affects Versions: 11.0.0.Final, 10.1.0.Final
Environment: CentOS 7 with IPv6 ULA Address as server for Wildfly 10.1.0Final
Windows 10 as client
Both with Java 8u161 (64bit)
Reporter: Jens Popp
Assignee: Jeff Mesnil
Somehow Java behaves differently on Linux and Windows regarding the IPv6 Network
Interfaces. With a small programm you can test this:
Enumeration<NetworkInterface> interfaces =
NetworkInterface.getNetworkInterfaces();
while (interfaces.hasMoreElements()) {
NetworkInterface netInterface = interfaces.nextElement();
Enumeration<InetAddress> address = netInterface.getInetAddresses();
while (address.hasMoreElements()) {
InetAddress addr = address.nextElement();
if (addr instanceof Inet6Address) {
Inet6Address inet6addr = (Inet6Address) addr;
if (!inet6addr.isLinkLocalAddress() &&
!inet6addr.isLoopbackAddress())
System.out.println(netInterface.getName() +":"+
inet6addr.isLinkLocalAddress() +":"+ inet6addr +" - "+
inet6addr.getScopedInterface());
}
}
}
In windows the scope will only be set for Link Local, in CentOS also for ULA addresses.
If I lookup the JMS from a ULA address (without scope) e.g. with:
String JMS_CONNECTION_FACTORY_JNDI = "jms/RemoteConnectionFactory";
Context context = getApplicationManager().getConnectionHandler().getContext();
TopicConnectionFactory cf = (TopicConnectionFactory)
context.lookup(JMS_CONNECTION_FACTORY_JNDI);
The TopicConnectionFactory is ActiveMQJMSConnectionFactory. This factory receives a
TransportConfiguration from the server that includes the server scope (IPv6 Address with
NetworkInterface after % e.g. [fd00::d7dc:b4cc:2e2a:ea1%enp0s3]). Trying to create a topic
connection with the TopicConnectionFactory will fail, since the client does not know the
scope (enp0s3).
There is a bug fix in NettyConnector (HORNETQ-907) to strip this "%enp0s3"
scope, but this BugFix does not work. The fix uses the standard InetAddress methods to
parse the host String, which fails, if the host String contains a server scope (network
interface) not available on the client. This will only cause an exception, if server and
client have different names for the NetworkInterfaces! Testing e.g. on two identical Linux
machines will not uncover the problem!
I think the underlying problem is, that the lookup distributes the server scope in the
IPv6 Address. The scope should only be distributed for Link-local Addresses, for all other
addresses the scope should be stripped already on the server and not be distributed during
lookup.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)