Scheduled jobs can be re-triggered if there was a loss of connection between nodes in a cluster

• Type: Bug
• Status: Closed
• Resolution: Fixed
• Affects Version/s: 6.2.X EE, 7.0.1 CE GA2, Master
• Fix Version/s: 6.2.X EE, 7.0.0 DXP FP2, 7.0.0 DXP SP1, 7.0.3 CE GA4, 7.1.X, Master
• Component/s: Portal Services, Portal Services > Scheduler
• Labels:
  • liferay-digital-enterprise-70-sp1
  • liferay-fixpack-de-2-7010
  • liferay-fixpack-portal-125-6210
• Branch Version/s:
  7.0.x, 6.2.x
• Backported to Branch:
  Committed
• Story Points: 1.5
• Fix Priority: 3
• Git Pull Request: https://github.com/tinatian/liferay-portal/pull/223

Steps to Reproduce:

1. In a clustered environment startup first node (for now master node).
2. Startup second node (salve node).
3. Deploy in both nodes a simple scheduled job test portlet set to trigger every 10 minutes.
4. Activate log level to DEBUG for com.liferay.portal.scheduler.ClusterSchedulerEngine to be able to detect which is the node currently executing jobs.
5. Wait 10 minutes to check that the job gets correctly fired in the master node (optional, this step can be skipped, it's only to check that configuration is fine).
6. Before job's next execution simulate a loss of connection between both nodes.
7. Check, in the logs, that slave node is now also master and is going to execute jobs.
8. Before job's next execution enable again connection between both nodes.
9. After a while one of both nodes will be established as slave and will indicate in the logs that is no longer going to execute jobs.
10. Wait until master executes the job (for first or second time depending whether you skipped the optional step or not).
11. Before the job is executed another time simulate a loss of connection between both nodes.

Expected Results:
No job should be executed at this point until the expected time.

Actual Results:
Jobs get immediately fired in one of the nodes (the one which was a slave before breaking connection for a second time) independently of the expected time.