[adrian.brock]

JIRA task for 4.0.4:
http://jira.jboss.com/jira/browse/JBAS-2398

[belaban]

Just for the record:

I've tested this using 1.4 running the 3.2.6 AS and the second node being 1.5 running 4.0.3 final.

In the 1.4/3.2.6 node, the cluster service is using the:

bind_addr="67.19.124.42" in the cluster-service.xml

In the 1.5/4.0.3 node, I use the '-b' but, I don't explicitly set the bind_addr in any of the multiple jgroups configs. Is this what you mean, Bela, by binding to 0.0.0.0?

yes, did the 3.2 and 4.0.3 nodes see each other then ?

Also, is there any benefit to adding a bind_addr="${jboss.bind.address:0.0.0.0}" in each of the jgroups configurations, and having that be the default that ships with the server? It seems like I'm always adding it anyway with each node deployment I do.

No !!!!! 0.0.0.0 is not a valid address ! This is just the printed representation of a wildcard address ! Setting this will cause members *not* to find each other on some systems, and cause exceptions on others. Just omit the default, and JGroups will pick the first, non loopback, interface

[dsicore]

Just for the record:

I've tested this using 1.4 running the 3.2.6 AS and the second node being 1.5 running 4.0.3 final.

In the 1.4/3.2.6 node, the cluster service is using the:

bind_addr="67.19.124.42" in the cluster-service.xml

In the 1.5/4.0.3 node, I use the '-b' but, I don't explicitly set the bind_addr in any of the multiple jgroups configs. Is this what you mean, Bela, by binding to 0.0.0.0?

yes, did the 3.2 and 4.0.3 nodes see each other then ?

Yeah, that's the problem. They still see each other. That's why I'm trying to find a valid default (i.e. the bind_addr=${jboss.bind.address:0.0.0.0} ) so that we will never have this problem in a standard distro out of the box that is configurable via parameters to the start script. Otherwise, I'm editing eight different jgroups configs. Is there another representation of 0.0.0.0 that we can use?

[belaban]

Don't set a default then

[dsicore]

Then, they see each other. Which is bad.

Am I missing something?

[dsicore]

Also, I suppose that a '-bp' parameter to run.sh to set the bind port will work around this problem. But, I'm still wondering if there is something other than '0.0.0.0' that we can use if that doesn't work for the bind_addr.

[belaban]

Which box were you testing this on ? I want to write a small unit test (just using either multicast directly, or JGroups).
A QA box in Atlanta ?

[dsicore]

It's our Labs dev box which is my own in a colo I'm renting (A real JBoss box is on the way). I'll give you an account if that's cool with you.

I'll email you directly.

[belaban]

I just tested this is broken (on dev02 and dev03). So I guess we need different ports then.

[adrian.brock]

No !!!!! 0.0.0.0 is not a valid address ! This is just the printed representation of a wildcard address ! Setting this will cause members *not* to find each other on some systems, and cause exceptions on others. Just omit the default, and JGroups will pick the first, non loopback, interface

Isn't that the definition of 0.0.0.0? :-)
If JGroups wants to override what the network admin configured then there
should be an option to toggle this behaviour.

[belaban]

Yes, it is. However, you cannot set it with "0.0.0.0".
In C this is IF_ANY, which afair is a null value.
0.0.0.0 is not a valid A, B, C or D address.

[dsicore]

If that is the case, how do you specify to bind to all interfaces?

[belaban]

For multicast sockets, you have to bind to *every* available interface. For UDP ad TCP sockets, you just don't define a bind interface.
In JGroups, you can define

receive_on_all_interfaces="true"

or

receive_interfaces="eth0,eth1"

[dimitris]

Related to http://jira.jboss.com/jira/browse/JBAS-2398

I tried running latest jboss 4.x in all 3 configurations, on a WinXP box, using ./run and ./run -b <local-nic>, checking the listening ports with TCPView.

In the minimal & default config, run -b binds all listening ports to the specified address.

In the all config, run -b shows the folowing addresses bound to 0.0.0.0

cluster-service.xml
---------------------------
UDP 0.0.0.0:1102 (${jboss.partition.udpGroup:230.0.0.4}, 1102) - ha-jndi
UDP 0.0.0.0:45566 (${jboss.partition.udpGroup:228.1.2.3}, 45566)
TCP 0.0.0.0:49153 (fixed tcp port)
UDP 0.0.0.0:2807 (random udp port)

tc5-cluster.sar
--------------------------
UDP 0.0.0.0:45577 (${jboss.partition.udpGroup:230.1.2.3}, 45577)
TCP 0.0.0.0:49152 (fixed tcp port)
UDP 0.0.0.0:2804 (random udp port)

1) It seems to me that although the bound multicast UDP sockets are reported to be bound to 0.0.0.0, they are clearly configured with 230.0.0.4, 228.1.2.3, 230.1.2.3, so this seems like a winxp thing we could ignore ?

2) Both jgroup stacks, listen also to 1 fixed tcp port, and 1 random udp port each. What are exactly those and shouldn't (at least the TCP port) be bound to the ${jboss.bind.address} ?

[belaban]

1) You list the *multicast addresses*, these are *not* the bind addresses, and are *not* set by -b/--host !

2) I didn't see that we use ${jboss.bind.address} in cluster-service.xml/tc5-cluster-service.xml, we should do this.

I'm compiling jboss-4.0.x right now, will check myself