[ https://issues.jboss.org/browse/JBAS-8741?page=com.atlassian.jira.plugin.... ] Richard Achmatowicz updated JBAS-8741: -------------------------------------- Environment: Linux only Description: When starting the AS, we have the following four possible combinations of addresses / stacks: (i) IPv4 addresses with IPv4 stack (java.net.preferIPv4Stack=true) (ii) IPv6 addresses with IPv6 stack (java.net.preferIPv4Stack=false, java.net.preferIPv6Addresses=true) (iii) IPv4 addresses with IPv6 stack ( java.net.preferIPv4Stack=false, java.net.preferIPv6Addresses=false) The stack preference is specified by defining the above system properties; the addresses are specified as inputs to the -b and -u options of run.sh. There is an issue associated when using the combination IPv4 address / IPv6 stack. The issue is made up of two facts: Fact 1: When we initlaise a multicast socket for group communication, we can initialise it in one of two ways: (i) binding the multicast socket to a multicast address and port (known as "binding to mulicast") (ii) binding a multicast socket to a port only When using an IPv4 address on an IPv6 socket, we cannot bind to multicast. Fact 2: On LInux, there is a known problem, the promiscuous traffic problem, wherein if we have clusters X and Y running, cluster X can see and be influenced by messages from cluster Y, even if the multicast address they use are different. The promiscuous traffic problem can be solved on Linux by binding to multicast. Binding to multicast is not required by other operating systems. Problem: when running with an IPv4 multicast address on an IPv6 stack on Linux, we cannot bind to multicast, and so we have the promiscuous traffic problem oif we use this address / stack combination. was: The test cases org.jboss.test.util.test.TwiddleUnitTestCase.{testGet, testInvoke} are failing. One problem is that the twiddle option -o is not correctly handling IPv6 addresses; for example: [rachmatowicz@soa3 bin]$ ./twiddle.sh -o fec0:0:a16:ffff::13 get "jboss.system:type=Server" Started 15:17:53,066 ERROR [Twiddle] Exec failed org.jboss.util.NestedRuntimeException: For input string: "0:a16:ffff::13:1090"; - nested throwable: (java.lang.NumberFormatException: For input string: "0:a16:ffff::13:1090") at org.jboss.console.twiddle.Twiddle$1.getServer(Twiddle.java:208) at org.jboss.console.twiddle.command.MBeanServerCommand.getMBeanServer(MBeanServerCommand.java:64) at org.jboss.console.twiddle.command.GetCommand.execute(GetCommand.java:149) at org.jboss.console.twiddle.Twiddle.main(Twiddle.java:357) Caused by: java.lang.NumberFormatException: For input string: "0:a16:ffff::13:1090" at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48) at java.lang.Integer.parseInt(Integer.java:458) at java.lang.Integer.parseInt(Integer.java:499) at com.sun.jndi.url.rmi.rmiURLContext.getRootURLContext(rmiURLContext.java:86) at com.sun.jndi.toolkit.url.GenericURLContext.lookup(GenericURLContext.java:182) at javax.naming.InitialContext.lookup(InitialContext.java:392) at javax.management.remote.rmi.RMIConnector.findRMIServerJNDI(RMIConnector.java:1886) at javax.management.remote.rmi.RMIConnector.findRMIServer(RMIConnector.java:1856) at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:257) at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:248) at org.jboss.console.twiddle.Twiddle.createMBeanServerConnection(Twiddle.java:309) at org.jboss.console.twiddle.Twiddle.connect(Twiddle.java:318) at org.jboss.console.twiddle.Twiddle.access$400(Twiddle.java:60) at org.jboss.console.twiddle.Twiddle$1.getServer(Twiddle.java:204) ... 3 more This is a typical IPv6 URL creation issue, as the issue can be fixed by surrouning the IPv6 address literal in square brackets: [rachmatowicz@soa3 bin]$ ./twiddle.sh -o [fec0:0:a16:ffff::13] get "jboss.system:type=Server" Started Started=true -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBAS-8741?page=com.atlassian.jira.plugin.... ] Richard Achmatowicz updated JBAS-8741: -------------------------------------- Complexity: High (was: Low) -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBAS-8741?page=com.atlassian.jira.plugin.... ] Richard Achmatowicz updated JBAS-8741: -------------------------------------- Description: When starting the AS, we have the following three possible combinations of addresses / stacks: (i) IPv4 addresses with IPv4 stack (java.net.preferIPv4Stack=true) (ii) IPv6 addresses with IPv6 stack (java.net.preferIPv4Stack=false, java.net.preferIPv6Addresses=true) (iii) IPv4 addresses with IPv6 stack ( java.net.preferIPv4Stack=false, java.net.preferIPv6Addresses=false) The stack preference is specified by defining the above system properties; the addresses are specified as inputs to the -b and -u options of run.sh. Many versions of the AS force an IPv4 stack by setting java.net.preferIPv4Stack=true in run.sh when on Linux. There is an issue associated when using the combination IPv4 address / IPv6 stack. The issue is made up of two facts: Fact 1: When we initlaize a multicast socket for group communication, we can initialise it in one of two ways: (i) binding the multicast socket to a multicast address and port (known as "binding to mulicast") (ii) binding a multicast socket to a port only When using an IPv4 address on an IPv6 socket, we cannot bind to multicast. Fact 2: On certain versions of Linux, HPUX and MacOSX there is a known problem, the promiscuous traffic problem, wherein two distinct clusters X and Y can see and be influenced by each other's messages, if the multicast address they use are different, but they use the same multicast ports. A general description of the promiscuous traffic can be found here: https://community.jboss.org/wiki/PromiscuousTraffic The promiscuous traffic problem can be solved on Linux by binding to multicast. Problem: when running with an IPv4 multicast address on an IPv6 stack on Linux, we cannot bind to multicast, and so we have the promiscuous traffic problem oif we use this address / stack combination. was: When starting the AS, we have the following three possible combinations of addresses / stacks: (i) IPv4 addresses with IPv4 stack (java.net.preferIPv4Stack=true) (ii) IPv6 addresses with IPv6 stack (java.net.preferIPv4Stack=false, java.net.preferIPv6Addresses=true) (iii) IPv4 addresses with IPv6 stack ( java.net.preferIPv4Stack=false, java.net.preferIPv6Addresses=false) The stack preference is specified by defining the above system properties; the addresses are specified as inputs to the -b and -u options of run.sh. Many versions of the AS force an IPv4 stack by setting java.net.preferIPv4Stack=true in run.sh when on Linux. There is an issue associated when using the combination IPv4 address / IPv6 stack. The issue is made up of two facts: Fact 1: When we initlaise a multicast socket for group communication, we can initialise it in one of two ways: (i) binding the multicast socket to a multicast address and port (known as "binding to mulicast") (ii) binding a multicast socket to a port only When using an IPv4 address on an IPv6 socket, we cannot bind to multicast. Fact 2: On LInux, there is a known problem, the promiscuous traffic problem, wherein if we have clusters X and Y running, cluster X can see and be influenced by messages from cluster Y, even if the multicast address they use are different. The promiscuous traffic problem can be solved on Linux by binding to multicast. Binding to multicast is not required by other operating systems. Problem: when running with an IPv4 multicast address on an IPv6 stack on Linux, we cannot bind to multicast, and so we have the promiscuous traffic problem oif we use this address / stack combination. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira