Q. Joining a cluster fails
Join can fail for several reasons, e.g. the coordinator crashed just before the new member joined.
When FD is used, it will take some time to discover the failed coord. A client will loop in the JOIN until the new coord has taken over. To troubleshoot this, it is useful to have:
a stack trace of the joiner and the coordinator (oldest member, who handles the JOIN)
logs: org.jgroups at the TRACE level, see JGroups Logging
the output of probe (see Probe protocol)
Q. What is this shunning thing, and should I turn it on or off ?
Check the page on shunning for details
Q. What is the version of JGroups ?
Execute from the command line:
java -cp jgroups.jar org.jgroups.Version
java -jar jgroups.jar
Q. Can JGroups bind to 0.0.0.0 ?
A bind address of 0.0.0.0 works for other JBoss services, but not for JGroups because the address plus port constitute the identity of a JGroups node, and 0.0.0.0 is not a valid address
Q. How do I bind TCP sockets to all interfaces?
In order to bind to all network interfaces:
add receive_interfaces (see example below) and
set -Dignore.bind.address=true, so that the values set in the XML files are taken
<TCP receive_interfaces="192.168.5.2,192.168.0.2" start_port="7800" ...></TCP>
Q. How does a JGroups transport protocol decide which address to bind to ?
There's two ways in which the bind address can be specified:
XML attribute in any of the transport protocols
The system property always overrides the XML property, unless you use the system property
(added at added at JGroups 2.2.8). Then it will use the bind_addr value from the config XML file.
Q. How do bind all JBoss services to the same IP address but have the JGroups traffic going over a different network (i.e. clustering)?
For JGroups 2.2.8 and later:
Use -Dignore.bind.address=true and the bind_addr attribute in the protocol stack config -- JGroup will now ignore the -b switch and use the bind_addr
For JGroups 2.2.7 and earlier:
In this case, you can't use ignore.bind.address because it was added in 2.2.8. Therefore, you would need to start AS something like this:
$ run.sh -b 192.168.1.10 -Dbind.address=10.0.0.10
Note that for releases prior to 4.0.5.GA the -Dbind.address part must come after the -b part. When the AS parses the command line args, the -b switch sets two system properties -- jboss.bind.address and bind.address. JGroups uses the latter. If you specifically set bind.address after -b is parsed, that value will be preserved and JGroups will use it. For 4.0.5.GA and later it doesn't matter in what order you specify things; if you set -Dbind.address, the value you pass will be used by JGroups.
Q. Merging does not occur even though Shunning is disabled, what could be the problem ?
Q. I get an "java.net.BindException: Cannot assign requested address exception"
If you get an exception like this, then, switch to IPv4 with -Djava.net.preferIPv4Stack=true. This is quite likely due to trying to use IPv6 in Linux but Sun's JDK has a bug that won't be fix until Java 6. See IPv6
Caused by: java.lang.Exception: problem creating sockets (bind_addr=/fe80:0:0:0:217:a4ff:fe10:3ee7%3, mcast_addr=null) at org.jgroups.protocols.UDP.start(UDP.java:372) at org.jgroups.stack.Protocol.handleSpecialDownEvent(Protocol.java:589) ... 1 more Caused by: java.net.BindException: Cannot assign requested address at java.net.PlainDatagramSocketImpl.bind0(Native Method) at java.net.PlainDatagramSocketImpl.bind(PlainDatagramSocketImpl.java:82) at java.net.DatagramSocket.bind(DatagramSocket.java:368) at java.net.DatagramSocket.<init>(DatagramSocket.java:210) at java.net.DatagramSocket.<init>(DatagramSocket.java:261) at org.jgroups.protocols.UDP.createEphemeralDatagramSocket(UDP.java:572) at org.jgroups.protocols.UDP.createSockets(UDP.java:436) at org.jgroups.protocols.UDP.start(UDP.java:367)
Q. During a load test, I get: "ERROR org.jgroups.blocks.GroupRequest both corr and transport are null, cannot send group request", how do I get around it?
This error message can appear under high load. Upping the FD timeout setting should make this error dissapear. In fact, it's recommended to have an combined FD and FD_SOCK failure detection mechanism as explained in FDVersusFD_SOCK, with a high FD timeout.