Cool; looking forward to 4.2!

Jacob,

I haven't forgotten. But updating that page is not what this issue was about, and the multicast configuration functionality has been coded and committed to the mainline, so this issue is closed/fixed with the changes to be released in 4.2.

I'll update the documentation, but I'm working on something else higher priority right now.

Thanks!
Bryan Turner
Atlassian Bitbucket

I see this was closed as fixed, but https://confluence.atlassian.com/bitbucketserver/installing-bitbucket-data-center-776640166.html doesn't appear to have been updated?

Jacob,

I'll take some scissors to our documentation for our join methods and see if I can't get it to more clearly convey the way the TCP/IP join method works. Thanks for taking the time to respond and help me understand where our documentation was lacking.

Best regards,
Bryan Turner
Atlassian Bitbucket

That's good clarification; thanks! Can you get the documentation updated to explain this as well as you just did?

Interesting about Confluence 5.9. What the presentation said was they are getting rid of multicast...I suppose that doesn't necessarily mean that it will be like JIRA. See at 27:00 in https://www.youtube.com/watch?v=Hstju8AFGWg Maybe it's more like Bitbucket? One of the evangelists we met with indicated Confluence was going to be "like JIRA." I suppose "like" doesn't mean identical... We're getting wrapped up in semantics.

Jacob,

You don't need to explicitly define all of the cluster members when you use the TCP/IP join method. You need to define some jump nodes (even just a single one would be enough). When nodes come up, they don't all need to be explicitly listed. They will connect to the listed jump node and negotiate joining the cluster. Listing two jump nodes is a good idea just in case either is down. Once you have your jump nodes listed, as long as their IP addresses don't change, you can shrink and grow the cluster without any further changes.

If you did need to change the configured jump node IPs, it should not require an outage. Just modify bitbucket.properties (formerly stash-config.properties) and list the new IPs and start the new nodes. Assuming any of your updated jump nodes is a node that's still up and in the cluster, the new nodes will simply start and join in. No downtime is required because there's no need to shutdown any of the nodes you already have running.

I've reached out directly to the Confuence team and they have confirmed that 5.9 has been updated to allow exactly the same configuration Bitbucket Server/Stash already had. It's still not done the same way JIRA is.

Best regards,
Bryan Turner
Atlassian Bitbucket

How does JIRA determine cluster nodes? I understand it uses the database? Confluence is supposed to be the same as JIRA in 5.9. We like how JIRA 7.0 does clustering, so that means Bitbucket would be the one app that's inconsistent.

To be clear, I don't want to explicitly define cluster members (this makes configuration much more difficult and requires an outage to change members). We aren't doing this in JIRA, and our multicast network only works on very specific IPs. So, either JIRA got lucky and picked a good multicast IP, or it does something different to determine members (we don't explicitly define them).

Jacob,

Also, one small clarification. Confluence will still be using Hazelcast, as does Bitbucket Data Center. Hazelcast supports multicast, TCP/IP and AWS join methods for creating clusters, however, not just multicast. They're not removing Hazelcast; they're just adding in the ability to configure the TCP/IP join mechanism Hazelcast has always supported, and which Bitbucket Data Center has included configuration settings for from 3.5 when clustering was officially released.

Best regards,
Bryan Turner
Atlassian Bitbucket

Jacob,

Bitbucket Server/Stash never required multicast. Every version of the application that has supported clustering has supported using multicast or simply configuring an explicit list of TCP/IP addresses for the nodes that should be in the cluster.

Our documentation for setting up a Data Center installation describes the settings you can use to either enable multicast or explicit TCP/IP.

(Note that, as mentioned in the documentation, you don't need to list all of the nodes the cluster will hold. When you configure the list, the nodes coming up try to connect to the configured addresses and then, once they're part of the cluster, they automatically find out about any other nodes not on the list. It's effectively a jump list to let new nodes "find" the cluster.)

Best regards,
Bryan Turner
Atlassian Bitbucket

During Atlassian Summit last week it was mentioned that Confluence will be removing the multicast/hazelcast requirement in the next version. That means that Bitbucket is the only datacenter solution from Atlassian requiring it.

Could this issue be updated to request changing the clustering to be consistent with JIRA and Confluence by not using multicast/hazelcast?