JBossDeveloper

"damon.sicore@jboss.com" wrote:
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?

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.

"bela@jboss.com" wrote:

"damon.sicore@jboss.com" wrote:
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 ?

Don't set a default then

Then, they see each other. Which is bad.

Am I missing something?

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.

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 ?

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.

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

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.

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

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"

receive_interfaces="eth0,eth1"

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} ?

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