JBoss uses the JGroups library for cluster discovery. Have a look at JGroups' documentation. I don't know if JBoss uses JGroups 2 or 3 but I think there aren't that much differences for the configuration:
Yup, those are the configuration details I'm looking to enter - the question is, where do they go?
If I add them as parameters to the S3_PING section of domain.xml, then JBoss throws errors on startup, saying that they're unrecognised arguments.
Inside the protocol element you can include several property element.
The property element must have a name attribute which match the protocole perperty you need to set. The value of the property is the content of the property element.
Brilliant, that seems to work perfectly - thank you very much
Which moves me on to my next problem..
This seems to work fine for the first node in the cluster - I see a 'web' folder getting created in the S3 bucket, and there's an identifier file being uploaded. The second node fails, however - looks like it's timing out, for some reason:
[Server:jboss2-server] 04:31:44,217 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC00001: Failed to start service jboss.jgroups.channel.web: org.jboss.msc.service.StartException in service jboss.jgroups.channel.web: java.net.ConnectException: Connection timed out
Any ideas why one would work, but the other wouldn't? I would think that the configuration is the same across both nodes, as all the S3 details are in domain.xml, and the managed domain setup seems to be working without issue.
1 of 1 people found this helpful
Never mind, figured it out by poking through the S3 logs. The node that was working had an elastic IP assigned, and the one that was failing didn't. Associated an elastic IP with both instances, everything's working as expected.
but elastic IPs somehow defeat the point in having dicovery protocol.. you may try using a NAT instance if your instances are running inside a VPC and that way you can add more cluster nodes without adding more elastic IPs.