[
https://issues.apache.org/jira/browse/SLING-5387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15990641#comment-15990641
]
Chetan Mehrotra commented on SLING-5387:
----------------------------------------
bq. 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
Can we also add the "name" of the job as well (if present). In Oak we might
have multiple AsyncIndexUpdate instances configured. With current approach all
of them would end on same instance. So if the hash logic also considers the job
name then that would help here
> 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)
