[
https://issues.apache.org/jira/browse/SLING-5387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15986180#comment-15986180
]
Carsten Ziegeler commented on SLING-5387:
-----------------------------------------
I changed the algorithm to always use the class name of the job as the key and
the full hash (BigInteger) module the number of instances
First implementation at 1792848
The topology events are handled in the way described by Stefan - with the
caveat if a job is currently running while the topology changes we can't stop
them. Their is no way in Java to really stop a thread.
> Provide support for running singleton jobs on non leader cluster nodes also
> ---------------------------------------------------------------------------
>
> Key: SLING-5387
> URL: https://issues.apache.org/jira/browse/SLING-5387
> Project: Sling
> Issue Type: Improvement
> Components: Commons
> Reporter: Chetan Mehrotra
> Assignee: Carsten Ziegeler
> Fix For: Commons Scheduler 2.5.4
>
>
> With SLING-2979 support for running singleton jobs on specific instance was
> provided. In most cases we want to run a job as singleton and not want to
> "pin" it to specific nodes. For this {{scheduler.runOn}} needs to be set to
> {{SINGLE}}.
> However per [current
> implementation|https://github.com/apache/sling/blob/org.apache.sling.commons.scheduler-2.4.14/src/main/java/org/apache/sling/commons/scheduler/impl/QuartzJobExecutor.java#L64]
> {{SINGLE}} is treated as {{LEADER}}. This effectively causes *all singleton*
> jobs to get executed on leader only thus putting extra load.
> For better utilization of cluster resources it should be possible to
> distribute such singleton jobs on other cluster nodes and still ensure that
> singleton contract is honoured!
> We would like to make use of this feature to ensure Oak AsyncIndexTask to run
> on different cluster nodes (OAK-2749)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
