[ https://jira.jboss.org/jira/browse/JGRP-978?page=com.atlassian.jira.plugi... ] Richard Achmatowicz commented on JGRP-978: ------------------------------------------ There was a related issue created by Brian (JBAS-6873) to allow the AS to overcome this use of fixed diagnostics addresses by using the UDP protocol parameters: Some excerpts from email discussions follow: Richard: I found that the multicast binding errors mentioned below disappear if I add the following lines to the file $JBOSS_DIST/server/deploy/cluster/jgroups-channelfactory.sar/META-INF/jgroups-channelfactory-stacks.xml: enable_diagnostics="true" diagnostics_addr="ff02::1:2:5" diagnostics_port="7500" where the diagnostics multicast address and port were of my choosing. AS far as I know we don't have a property in the AS to specify these values. Here is the revised output: 16:35:19,970 INFO [DefaultPartition] Initializing partition DefaultPartition 16:35:20,231 WARN [UDP] could not bind to /ff02:0:0:0:0:1:2:3 (IPv6 address); make sure your mcast_addr is of the same type as the IP stack (IPv4 or IPv6). Will ignore mcast_addr, but this may lead to cross talking (see http://www.jboss.com/wiki/Edit.jsp?page=CrossTalking for details). Exception was: java.net.SocketException: Invalid argument 16:35:20,289 INFO [STDOUT] --------------------------------------------------------- GMS: address is fe80:0:0:0:215:17ff:fe2d:6821:44270 (cluster=DefaultPartition) --------------------------------------------------------- 16:35:20,491 INFO [PlatformMBeanServerRegistration] JBossCache MBeans were successfully registered to the platform mbean server. 16:35:22,387 INFO [DefaultPartition] Number of cluster members: 1 16:35:22,399 INFO [DefaultPartition] Other members: 0 16:35:22,609 INFO [RPCManagerImpl] Received new cluster view: [fe80:0:0:0:215:17ff:fe2d:6821:44270|0] [fe80:0:0:0:215:17ff:fe2d:6821:44270] 16:35:22,611 INFO [RPCManagerImpl] Cache local address is fe80:0:0:0:215:17ff:fe2d:6821:44270 16:35:22,615 INFO [RPCManagerImpl] state was retrieved successfully (in 2.03 seconds) 16:35:22,652 INFO [ComponentRegistry] JBoss Cache version: JBossCache 'Cascabel' 3.1.0.CR1 16:35:22,652 INFO [DefaultPartition] Fetching serviceState (will wait for 30000 milliseconds): 16:35:22,654 INFO [DefaultPartition] State could not be retrieved (we are the first member in group) 16:35:22,978 INFO [HANamingService] Started HAJNDI bootstrap; jnpPort=1100, backlog=50, bindAddress=/fe80:0:0:0:215:17ff:fe2d:6821 16:35:22,987 WARN [DetachedHANamingService$AutomaticDiscovery] could not bind to /ff02:0:0:0:0:1:2:3 (IPv6 address); make sure your mcast_addr is of the same type as the IP stack (IPv4 or IPv6). Will ignore mcast_addr, but this may lead to cross talking (see http://www.jboss.com/wiki/Edit.jsp?page=CrossTalking for details). Exception was: java.net.SocketException: Invalid argument 16:35:22,991 INFO [DetachedHANamingService$AutomaticDiscovery] Listening on /fe80:0:0:0:215:17ff:fe2d:6821%8:1102, group=ff02::1:2:3, HA-JNDI address=fe80:0:0:0:215:17ff:fe2d:6821:1100 16:35:24,457 INFO [UnifiedInvokerHA] Service name is jboss:service=invoker,type=unifiedha Don't know what you want to do about this? Create a JIRA? Brian: Are you asking whether there should be a JIRA for the requirement to configure the diagnostic_addr? Or the WARN for the binding to the multicast address? Re: the diagnostic address, there should be a JBAS JIRA to add this to the standard configs. And now there is. :) https://jira.jboss.org/jira/browse/JBAS-6873 That only applies to community AS 5.1, and hence EAP 5. For the EAP 4.x releases we are talking about, generally we don't like changing configurations in CP as it makes installing the CP harder. But, perhaps a well written JBPAPP JIRA would still be useful, even if we reject it as "Won't Fix". The JIRA would document the issue in the place people search for issues. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JGRP-978?page=com.atlassian.jira.plugi... ] Richard Achmatowicz commented on JGRP-978: ------------------------------------------ On a given host, we can have three possible cases of coexistence between IPv4 and IPv6: IPv4 only support, IPv6 only support or dual-stack IPv4 and IPv6 support. I have read informally that dual-stack support is not available on certain OSs (e.g. Windows XP, Windows 2003, OpenBSD) On dual stack machines, IPv6 has some special features for supporting the transition from IPv4 to IPv6. One of these is IPv4-mapped addresses, where an IPv4 address can be used together with the IPv6 API. This allows IPv4 clients to talk to IPv6 servers, for example. It also allows managing IPv4 clients and servers from an IPv6 interface. The IPv6 API is used at the transport level (e.g. TCP, UDP) when opening a socket. At the network level, however, the packets are shipped using IPv4. I don't know of (and I suspect there is not) a multicast address which is valid for both IPv4 and IPv6. Why isn't an IPv4 multicast address converted automatically to an IPv6 address in an IPv6-only environment? Possibly because multicast in IPv6 is scoped and so it would be difficult to know which scope to use for a given IPv4 multicast address. I guess this is mainly an issue of making all the defaults for IP addresses configurable, so the user has at least the option of implementing the workaround. It may be just a lot of unnecessary and error prone work to try to have JGroups detect the particular case of coexistence between IPv4 and IPv6 that it happens to be in. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JGRP-978?page=com.atlassian.jira.plugi... ] Richard Achmatowicz commented on JGRP-978: ------------------------------------------ Before closing, should we add something to the docs about this? The fact that diagnostics addresses are configurable, how to change the defaults, and that this may be required when running in an IPv6 environment? If you don't change the defaults for diagnostics, you get the unenviable situation where the user intends to use IPv6 and takes care to change his bind and multicast address, but diagnostics still uses IPv4. If the user has only adjusted his IPv6 firewall, the IPv4 diagnostics packets might not get through, and he may wonder why JGroups works but probe does not. The firewall issue may come into play with other non-diagnostics IPv4 defaults which are getting picked up, if there are any. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JGRP-978?page=com.atlassian.jira.plugi... ] Bela Ban commented on JGRP-978: ------------------------------- A stupid idea: why don't we pick an IPv4 multicast address *and* an IPv6 multicast address for the diagnostics address ? First we try to bind to the IPv4 mcast address, if this fails we fall back to binding to the IPv6 mcast address. Probe then also mcasts packets to both the IPv4 and IPv6 addresses... Of course, we should suppress some of the errors that will inevitable show up... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JGRP-978?page=com.atlassian.jira.plugi... ] Bela Ban commented on JGRP-978: ------------------------------- OK, so you want to do the following: if the bind_addr is (not null) and is an Inet6Address, then pick the IPv6 default for the diagnostics multicast address, else fall back to the IPv4 address. I think that's fine. Can you do that ? What do we do on the probe.sh side if -mcast_addr is not specified on the command line ? By default try the IPv4 mcast address ? Or both the IPv4 and IPv6 default mcast addresses ? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JGRP-978?page=com.atlassian.jira.plugi... ] Richard Achmatowicz commented on JGRP-978: ------------------------------------------ Bela Here are my thoughts on this issue: The problem ----------- A user starts up jgroups, possibly specifying values for the some of the IP addresses which JGroups makes use of: * UDP: bind_addr, mcast_addr, diagnostics_addr * TCP: bind_addr, initial_hosts The user can specify zero or more such values, relying on defaults if values are left unspecified. Possible Requirements ------------ 1. We want to make sure that the complete set of values is specified, before any sockets are created. 2. We assume that a mixed configuration of IPv4 and IPv6 addresses in one stack is unwanted. 3. The decision to use a set of addresses must agree with the stacks available (or preferred in the case of dual stack availability) on the host. Design for a solution (for UDP/TCP layers) --------------------- Idea: A. define defaults for all required IP address values above for both IPv4 and IPv6 B. at stack initialization, collect up all the values specified by the user (after parameters processing in UDP/TCP) C. - if one or more values specified: D. - check if a consistent set of either IPv4 or IPv6 addresses E. - if not consistent set, raise exception and don't start stack F. - if consistent set, set useIPv4/useIPv6 variable to record the consistency, and complete the set with appropriate defaults // NOTE: this takes the user's decision on IPv4 vs IPv6 and goes with it, making no checks to see if the // chosen stack is available on the machine. The user may receive Socket exceptions is the stack // is not available, or if the stack preference (java.net.preferIPv4Stack) is set differently from the users choice // on a dual stack machine. G. - if zero values specified: H. - check to see which stacks are available on the machine (by enumerating all network interfaces and for each, checking if IPv4 or IPv6 addresses are defined) and set the values isIPv4Available/isIPv6Available I. - if only IPv4 is available, set useIPv4=true and complete the set of approproate defaults J. - if only IPv6 is available, set useIPv6=true and complete set of appropriate defaults K. - if both IPv6 and IPv4 are available, use JVM property java.net.preferIPv4Stack value to decide which stack to use and complete the set of appropriate defaults // NOTE: this checks the presence of the IPv4 and IPv6 stacks, and chooses one, taking into account the JVM stack preference // setting. This determines uniquely whether IPv4 or IPv6 sockets will be created by the JVM. This may result in IPv4 addresses being // used with IPv6 sockets (and so IPv4-mapped addresses used internally). L. before sockets are created, we end up with the following values set: useIPv4/useIPv6, which indicates which IP stack was chosen, based on user specifying values (or not) isIPv4Available/isIPv6Available which indicates which stacks are available a complete consistent set of values for the IP addresses that JGroups needs This design does not meet requirement 3 if the user specifies one or more values. That is, he could specify IPv6 addresses when in fact the JVM has only an IPv4 stack available, or has a preference for an IPv4 stack. That could be changed by additionally checking if the consistent set of values specified by the user also is supported with a stack on the host (as is done in the case where no values are specified). Don't know how involved you want JGroups to be in checking IP address configuratioin. This could be achieved for little extra cost by checking stack availability before hand. With respect to probe.sh/Probe.java, I believe we need to also check what kind of stacks we have available in order to be able to multicast, without handling exceptions for stacks not being available. This would keep all the IP version stuff separate from the general code. For the case of TCPPING and making defaults for initial_hosts consistent, could this be done within TCPPING when it received the LOCAL_ADDR and check consistency between LOCAL_ADDR and its initial hosts parameters? If the address passed in by LOCAL_ADDR and the specified values for initial_hosts don't agree, then raise an exception and don't start the stack. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JGRP-978?page=com.atlassian.jira.plugi... ] Richard Achmatowicz commented on JGRP-978: ------------------------------------------ I'm starting to look at the details of the implementation. There are three cvs repos I cound with 2.8 associated with them: HEAD -> 2.8.Beta1 Branch_JGroups_2_8_LogicalAddresses Branch_2_8_temp which one should changes be applied to? I assume HEAD? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JGRP-978?page=com.atlassian.jira.plugi... ] Richard Achmatowicz commented on JGRP-978: ------------------------------------------ Bela I've attached a preliminary version of the algorithm to check for version consistent addresses in the case of UDP. Some utilities are missing, but this will give you the idea. The idea is that if any of bind_addr, mcast_addr, diagnostics_addr or bind_interface are non-null, then the user has specified them and these should be used in calculating the complete set of addresses, those specified as well as required defaults. bind_addr posed a challenge, as it is set based on any value passed for bind_interface. It just introduces more cases which need to be checked. I had to move bind_addr processing from TP.setProperties() to UDP.init() - it was happening too early and can be influenced by values for mcast_addr and diagnostics_addr. I'm stuck doing EAP stuff at the moment (again) so it may not be until next week before I get a chance to finish this and commit it. Any feedback welcomed.. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JGRP-978?page=com.atlassian.jira.plugi... ] Richard Achmatowicz commented on JGRP-978: ------------------------------------------ One of the requirements for being able to implement this task is to move assigment of all addresses which may need defaults assigned (i.e. bind_addr, mcast_addr, diagnostics_addr and related addresses such as external_addr) to a single point in the startup of the stack, namely X.init() where X = {UDP, TCP, TCP-NIO, LOOPBACK, SHARED_LOOPBACK, TUNNEL}. This is after properties from the user have been processed, and before sockets are allocated in X.start(). Previously, assignment of addreses was being done: (i) during Properties processing (ii) during TP.init() (iii) during X.init() processing (iiv) during X.start() processing I have now placed all this processing in the following locations: UDP.init() BasicTCP.init() SHARED_LOOPBACK.init() TUNNEL.init() LOOPBACK.init() So addresses are being assigned exactly as before, but now always in init(). Now that this is complete, the algorithm which calculates the desired IP version and and assigns the addresses can be simply performed during init() as well. Plan to test that for the first time tomorrow. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira