-
Type:
Bug
-
Resolution: Unresolved
-
Priority:
Low
-
None
-
Affects Version/s: 8.5.14
-
Component/s: Server - Jobs
-
None
-
3
-
Severity 3 - Minor
-
0
Issue Summary
The following per cluster schedule job doesn't run if any clustered node is down. The following jobs have been verified until now; if more jobs are identified, they can be added to the list below. This has been verified in 2-node and 3-node cluster.
- Send Batched Notifications
- Send Recommended Updates Email
This is reproducible on Data Center: (yes) / (no) Yes
Steps to Reproduce
- Create a multi-node Confluence DC cluster by selecting confluence.cluster.join.type as tcp_ip.
- Add an SMTP server using the instruction provided here.
- Make some changes to a page, add comments, and verify you receive an email for changes as per the next run Send Batched Notifications batch job.
- Stop one node of the cluster.
Expected Results
The batch jobs should get scheduled and run on the online nodes as per the next schedule.
Actual Results
The batch job does not run until all the nodes are up in the cluster. The manual run succeeds but does not update the Last Execution column of Schedule job screen.
If you have modified the job schedule, it will reset to the default 10 minutes.
- Edit schedule screen of the job shows it should run every 2 mins.

- But the Schedule job screens shows different timestamp for Next execution in column 4.

Workaround
Workaround 1:
Remove the node that is down in the cluster from the confluence.cluster.peers property in confluence.cfg.xml and restart the available nodes. After this, the job runs according to the defined schedule.
Workaround2:
Switch to Mulitcast cluster join type. Please ensure your Confluence host supports Multicast if not please work with your Network administrator to implement and test. Following are the steps to switch over to Multicast.
- Take a backup of confluence.cfg.xml.
- Edit it and make the following changes on all the nodes.
//Update <property name="confluence.cluster.join.type">tcp_ip</property> //To <property name="confluence.cluster.join.type">multicast</property>
- Add a multicast address and ttl using the following property. Please get a valid multicast address from your Network team.
<property name="confluence.cluster.address">xxx.xxx.xxx.xxx</property> <property name="confluence.cluster.ttl">1</property>
- Remove the following line:
<property name="confluence.cluster.peers">xxx.xxx.xxx.xxx,xxx.xxx.xxx.xxx</property>
- Start one node, wait for it to come properly, and ensure Confluence is accessible from the browser. Verify in the atlassian-confluence.log file below lines are printed showing cluster forming using a multicast address.
2024-12-17 19:35:27,009 INFO [http-nio-8090-exec-6] [atlassian.confluence.cluster.DefaultClusterConfigurationHelper] createCluster Creating new cluster with configuration ClusterConfig: localdocker/Multicast (address|port|TTL): (xxx.xxx.xxx.xxx|54327|1), Interface:name:eth0 (eth0) 2024-12-17 19:35:27,072 INFO [http-nio-8090-exec-6] [confluence.cluster.hazelcast.HazelcastClusterManager] configure Configuring Hazelcast with instanceName [confluence], join configuration Multicast (address|port|TTL): (xxx.xxx.xxx.xxx|54327|1), network interfaces [xxx.xxx.xxx.xxx] and local port 5801
- Start the second node and ensure it joins the cluster on the provided multicast address.