[rachmato]

Yes, that is the way to specify properties of protocols in XML. Thanks, Rado :-)

[akostadinov]

crap! started a router with:

java -classpath /usr/share/java/commons-logging.jar:/usr/share/java/jgroups.jar org.jgroups.stack.GossipRouter -port 5555 -bindaddress localhost

then transformed standalone-ha.xml with the attached gossip.xsl:

xsltproc gossip.xsl standalone-ha.xml

then started JBoss AS 7 with:

bin/standalone.sh -c standalone-ha.xml

finally in jboss-cli:

deploy --force /usr/share/java/jboss-ec2-eap-samples/cluster-demo.war

But after the last step I see in the logs:

MSC000001: Failed to start service jboss.jgroups.channel.web: org.jboss.msc.service.StartException in service jboss.jgroups.channel.web: java.lang.IllegalArgumentException: the following properties in TCPGOSSIP are not recognized: {gossip_refresh_rate=5000}

Any ideas why this prop unavailable (running EAP 6.0.0)?

UPDATE: uploading gossip2.xsl as a working version for jgroups 3+

[rachmato]

You're using both gossip_refersh and gossip_refresh_rate in the xsl file. Isn't the correct one gossip_refresh?

[akostadinov]

gossip_refresh is for the PING protocol and gossip_refresh_rate is for the TCPGOSSIP protocol. According to documentation that should be correct. To be honest, just to be sure, I tried also "gossip_refresh", "refresh" and "refresh_rate" but all of these trigger the same error.

[rachmato]

Aleks

Checked the source code for JGroups 3.0.11 and couldn't find these properties any longer.

Double-checked with Bela and he confirmed thet have been removed. Reason for the removal was that the refresh rate was used to check registrations with the GossipRouter , but as TCP connections are being used, the registrations can be checked by noting that a TCP connection is not closed.

The updated manual pages: http://www.jgroups.org/manual-3.x/html/protlist.html#d0e4375

So they can safely be left out. Ping Bela if yuou need more detailed info on this.

[akostadinov]

Thank you Richard, for taking the time to look at this. This perfectly makes sense. Skipping the option looks to be working fine. At least no errors in the log...

UPDATE: hmm, it seems like TCPGOSSIP is now used for TCP as well UDP protocols. PING does not accept gossip properties any more.

[akostadinov]

It depends where muticast traffic is routed to. You need to bind to the interface muticast traffic is routed to.

Also please be aware that multiple processes binding to the same interface and port but joining different mcast groups would receive the same messages. So if you are running two clusters on the same interface, it is advisable to choose different port numbers for the multicast traffic. Otherwise you may see all machines joining the same cluster. See https://bugzilla.redhat.com/show_bug.cgi?id=231899 for more details and test applications (IPv4 and IPv6).

Hope that helps. Pleaese mark thread as answered even if you found part or whole answer by yourself.