-
Bug
-
Resolution: Done
-
Critical
-
1.2.6.Final, 1.3.0.Beta1
-
None
Depending on the actual operating system and IPv6 UDP multicast address chosen one may encounter the infamous java.net.SocketException: Invalid argument while attempting to bind both to address and port.
Global scope addresses such as ff0e::1 seems to work, but any ff02::1 (local network nodes) or even ff01::9 (interface local) causes java.net.SocketException: Invalid argument with new InetSocketAddress(address, port). The solution, according to JGroups and mod_cluster subsystem code appears to be simply to sacrifice possible cross-talking and bind to port only, all multicast addresses: new InetSocketAddress(port).
The problem is that while, for instance, mod_cluster subsystem code is prepared for this eventuality on Linux-like systems and catches the exception:
mod_cluster warning, continues to operate
WARN [org.jboss.modcluster] (ServerService Thread Pool -- 62) MODCLUSTER000031: Could not bind multicast socket to /ff01:0:0:0:0:0:0:9 (IPv6 address): Invalid argument; make sure your multicast address is of the same type as the IP stack (IPv4 or IPv6). Multicast socket will not be bound to an address, but this may lead to cross talking (see http://www.jboss.org/community/docs/DOC-9469 for details).
DEBUG [org.jboss.modcluster] (ServerService Thread Pool -- 62) Catching: java.net.SocketException: Invalid argument
at java.net.PlainDatagramSocketImpl.bind0(Native Method)
at java.net.AbstractPlainDatagramSocketImpl.bind(AbstractPlainDatagramSocketImpl.java:94)
at java.net.DatagramSocket.bind(DatagramSocket.java:392)
at java.net.MulticastSocket.<init>(MulticastSocket.java:172)
at org.jboss.modcluster.advertise.impl.MulticastSocketFactoryImpl.createMulticastSocket(MulticastSocketFactoryImpl.java:82)
at org.jboss.modcluster.advertise.impl.AdvertiseListenerImpl.init(AdvertiseListenerImpl.java:145)
at org.jboss.modcluster.advertise.impl.AdvertiseListenerImpl.start(AdvertiseListenerImpl.java:165)
at org.jboss.modcluster.ModClusterService.init(ModClusterService.java:181)
at org.wildfly.mod_cluster.undertow.UndertowEventHandlerAdapter.start(UndertowEventHandlerAdapter.java:98)
at org.wildfly.clustering.service.AsynchronousServiceBuilder$1.run(AsynchronousServiceBuilder.java:102)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
at org.jboss.threads.JBossThread.run(JBossThread.java:320)
try { return new MulticastSocket(new InetSocketAddress(address, port)); } catch (IOException e) { ModClusterLogger.LOGGER.potentialCrossTalking(address, (address instanceof Inet4Address) ? "IPv4" : "IPv6", e.getLocalizedMessage()); ModClusterLogger.LOGGER.catchingDebug(e); return new MulticastSocket(port); }
the Undertow mod_cluster proxy code does not handle the exception appropriately and causes the whole operation to shut down, which is unnecessary:
Undertow mod_cluster proxy failure
ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.undertow.filter.mod-cluster: org.jboss.msc.service.StartException in service jboss.undertow.filter.mod-cluster: Failed to start service
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.RuntimeException: java.net.SocketException: Invalid argument
at org.wildfly.extension.undertow.filters.ModClusterService.start(ModClusterService.java:103)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
... 3 more
Caused by: java.net.SocketException: Invalid argument
at sun.nio.ch.Net.bind0(Native Method)
at sun.nio.ch.Net.bind(Net.java:437)
at sun.nio.ch.DatagramChannelImpl.bind(DatagramChannelImpl.java:691)
at sun.nio.ch.DatagramSocketAdaptor.bind(DatagramSocketAdaptor.java:91)
at org.xnio.nio.NioXnioWorker.createUdpServer(NioXnioWorker.java:216)
at io.undertow.server.handlers.proxy.mod_cluster.MCMPAdvertiseTask.advertise(MCMPAdvertiseTask.java:71)
at io.undertow.server.handlers.proxy.mod_cluster.ModCluster.advertise(ModCluster.java:159)
at org.wildfly.extension.undertow.filters.ModClusterService.start(ModClusterService.java:101)
... 5 more
if (group != null && linuxLike) { bindAddress = new InetSocketAddress(group, config.getAdvertisePort()); } else { bindAddress = new InetSocketAddress(config.getAdvertisePort()); } final MulticastMessageChannel channel = worker.createUdpServer(bindAddress, new ChannelListener<MulticastMessageChannel>() { @Override public void handleEvent(MulticastMessageChannel channel) { //channel.resumeWrites(); } }, OptionMap.EMPTY);
Call to action
IMHO, we should handle the situation in Undertow mod_cluster proxy the same way as it is handled in mod_cluster subsystem code and JGroups.
WDYT?
- clones
-
-
- Closed
-