[ 
https://issues.apache.org/jira/browse/SLING-5387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15986202#comment-15986202
 ] 

Stefan Egli commented on SLING-5387:
------------------------------------

bq. with the caveat if a job is currently running while the topology changes we 
can't stop them.
we could in theory support this part as wel by delaying the new scheduler to 
take over while the old scheduler still has a job running. That would mean we'd 
need an additional hand-over phase. This could be done similar to the 
ClusterSyncService of discovery.commons. Unfortunately it can't be done just 
with the discovery API alone. What we'd need is something like a 
{{ClusterView.getSeqNum()}} and then based on that each instance could give its 
OK that it has no jobs running from a previous clusterview sequence number (and 
store that in the repository for example). Or perhaps the ClusterViewService 
itself could be generalized to be usable by non-implementors.

> 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)

Reply via email to