[javagroups-users] Handling of IPv6 mcast_addrs

[Bela B. <be...@ya...>]

In 2.8, we changed the way IP addresses are handled. Below, I want to 
briefly describe an issue I ran into, and the corresponding fix, but 
wanted to solicit feedback, as this will change things a bit.

The type of a stack (IPv4, IPv6 or dual) is determined by the installed 
stacks and the system props java.net.preferIPv4Stack (default: false) 
and java.net.preferIPv6Addresses (default: false).

#1 If only preferIPv4Stack is set, then we use IPv4.

#2 If only preferIPv6Addresses is set, we use IPv6.

#3 If both are set, we use IPv4.

#4 If neither is set, we use IPv6 (!)


Now if we have a config such as

CONFIG-1: <UDP mcast_addr="232.5.5.5" ... /> // IPv4 mcast_addr
CONFIG-2: <UDP mcast_addr="ff0e::8:8:8" ... /> // IPv6 mcast_addr

, then the following can happen (assuming we have both types of stack 
available):

We run without any java.net.preferXXX props:

    * The stack is IPv6 by default
    * CONFIG-1 will fail because we passed an IPv4 address to an IPv6 stack

We run with preferIPv4Stack=true:

    * The stack is IPv4
    * CONFIG-2 will fail as we're running with an IPv4 stack

Both props are set:

    * CONFIG-2 will fail, same as above

*So my proposal is to remove all properties from the shipped XML 
configurations that have IP addresses, e.g. bind_addr (not used anywhere 
though) and UDP.mcast_addr.*

This will allow for the case where no java.net.preferXXX props are set; 
it will not fail (it currently does fail !) because we're picking a 
stack type compliant (IPv6) mcast_addr.

I assume a lot of folks trying out JGroups for the first time don't 
bother even reading the documentation and will *not* set a 
java.net.preferXXX system property, and would therefore run into an 
exception when using a current sample config file, e.g. udp.xml. This 
won't happen with the proposed change.

Folks who want to force a specific stack type and use specific IP 
addresses, have to (1) define the right values in the XML config (or 
pass them to JGroups via system props) and (2) possibly set a 
java.net.preferXXX system property (not needed if the default is what a 
user wants).

What do people think ? Feedback appreciated !


-- 
Bela Ban
Lead JGroups / Clustering Team
JBoss