[jira] [Commented] (SLING-5831) Support different thread pools for scheduled tasks
[ https://issues.apache.org/jira/browse/SLING-5831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15385374#comment-15385374 ] Chetan Mehrotra commented on SLING-5831: Fine with me! > Support different thread pools for scheduled tasks > -- > > Key: SLING-5831 > URL: https://issues.apache.org/jira/browse/SLING-5831 > Project: Sling > Issue Type: Improvement > Components: Commons >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Labels: docs-impacting > Fix For: Commons Scheduler 2.4.16 > > > Right now the scheduler uses a single thread pool. While this thread pool can > be configured, it means that all scheduled tasks share this pool. In order to > prioratize different tasks over others and avoid blocking important jobs > through unimportant once, we could maybe add a configuration property to > select a thread pool name. > If a pool with that name exists, it's used - if not the default is used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-5831) Support different thread pools for scheduled tasks
[ https://issues.apache.org/jira/browse/SLING-5831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15385366#comment-15385366 ] Carsten Ziegeler commented on SLING-5831: - If removeJob did not throw in previous versions, this was clearly a bug. I know that it did so in the early versions and the API clearly states that removeJob throws. So I think we're totaly fine and callers of removeJob must except that exception. Can we consider this issue done? > Support different thread pools for scheduled tasks > -- > > Key: SLING-5831 > URL: https://issues.apache.org/jira/browse/SLING-5831 > Project: Sling > Issue Type: Improvement > Components: Commons >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Labels: docs-impacting > Fix For: Commons Scheduler 2.4.16 > > > Right now the scheduler uses a single thread pool. While this thread pool can > be configured, it means that all scheduled tasks share this pool. In order to > prioratize different tasks over others and avoid blocking important jobs > through unimportant once, we could maybe add a configuration property to > select a thread pool name. > If a pool with that name exists, it's used - if not the default is used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-5831) Support different thread pools for scheduled tasks
[ https://issues.apache.org/jira/browse/SLING-5831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15385355#comment-15385355 ] Chetan Mehrotra commented on SLING-5831: bq. For removeJob(), the API states that a NoSuchElementException is thrown if the job can't be found, so I think the behaviour is correct now. To avoid the exception, you can replace removeJob() with unschedule() (removeJob is deprecated) Ack. However this is a behaviour change and bit unrelated to current issue. So may be addressed in different issue. Problem is this would cause such exception when new Scheduler bundle is used in older setup where other bundles are not updated > Support different thread pools for scheduled tasks > -- > > Key: SLING-5831 > URL: https://issues.apache.org/jira/browse/SLING-5831 > Project: Sling > Issue Type: Improvement > Components: Commons >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Labels: docs-impacting > Fix For: Commons Scheduler 2.4.16 > > > Right now the scheduler uses a single thread pool. While this thread pool can > be configured, it means that all scheduled tasks share this pool. In order to > prioratize different tasks over others and avoid blocking important jobs > through unimportant once, we could maybe add a configuration property to > select a thread pool name. > If a pool with that name exists, it's used - if not the default is used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-5831) Support different thread pools for scheduled tasks
[ https://issues.apache.org/jira/browse/SLING-5831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15383677#comment-15383677 ] Carsten Ziegeler commented on SLING-5831: - Thanks for reporting [~chetanm] I've added a null check in activate(). For removeJob(), the API states that a NoSuchElementException is thrown if the job can't be found, so I think the behaviour is correct now. To avoid the exception, you can replace removeJob() with unschedule() (removeJob is deprecated) > Support different thread pools for scheduled tasks > -- > > Key: SLING-5831 > URL: https://issues.apache.org/jira/browse/SLING-5831 > Project: Sling > Issue Type: Improvement > Components: Commons >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Labels: docs-impacting > Fix For: Commons Scheduler 2.4.16 > > > Right now the scheduler uses a single thread pool. While this thread pool can > be configured, it means that all scheduled tasks share this pool. In order to > prioratize different tasks over others and avoid blocking important jobs > through unimportant once, we could maybe add a configuration property to > select a thread pool name. > If a pool with that name exists, it's used - if not the default is used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-5831) Support different thread pools for scheduled tasks
[
https://issues.apache.org/jira/browse/SLING-5831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15383602#comment-15383602
]
Chetan Mehrotra commented on SLING-5831:
Tried using the snapshot version to check with Oak.
# Startup threw NPE as {{allowedPoolNames}} was null. So that would need to be
initialized
{noformat}
2016-07-19 10:38:40,639 ERROR NA [FelixStartLevel] o.a.sling.commons.scheduler
- [org.apache.sling.commons.scheduler.impl.QuartzScheduler(156)] The activate
method has thrown an exception (java.lang.NullPointerException)
java.lang.NullPointerException: null
at
org.apache.sling.commons.scheduler.impl.QuartzScheduler.activate(QuartzScheduler.java:137)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.apache.felix.scr.impl.helper.BaseMethod.invokeMethod(BaseMethod.java:222)
at
org.apache.felix.scr.impl.helper.BaseMethod.access$500(BaseMethod.java:37)
at
org.apache.felix.scr.impl.helper.BaseMethod$Resolved.invoke(BaseMethod.java:615)
at
org.apache.felix.scr.impl.helper.BaseMethod.invoke(BaseMethod.java:499)
at
org.apache.felix.scr.impl.helper.ActivateMethod.invoke(ActivateMethod.java:295)
{noformat}
# If some job is unregistered which was probably not registered (not sure of
scenario) then it logs following exception. It does not used to come so far.
Looking at {{removeJob}} logic I think it would now throw exception if job was
not registered. While earlier a remove job would have just been a noop if job
did not existed. So may be
{noformat}
2016-07-19 10:55:00,357 ERROR NA [CM Event Dispatcher (Fire ConfigurationEvent:
pid=org.apache.sling.commons.scheduler.impl.QuartzScheduler)]
c.a.g.w.c.m.WorkflowStatsMBeanImpl - Failed to schedule workflow mbean job
java.util.NoSuchElementException: No job found with name
com.adobe.granite.workflow.core.mbean.WorkflowStatsMBean
at
org.apache.sling.commons.scheduler.impl.QuartzScheduler.removeJob(QuartzScheduler.java:453)
at
org.apache.sling.commons.scheduler.impl.SchedulerServiceFactory.removeJob(SchedulerServiceFactory.java:188)
at
com.adobe.granite.workflow.core.mbean.WorkflowStatsMBeanImpl.unscheduleSelf(WorkflowStatsMBeanImpl.java:293)
at
com.adobe.granite.workflow.core.mbean.WorkflowStatsMBeanImpl.scheduleSelf(WorkflowStatsMBeanImpl.java:280)
at
com.adobe.granite.workflow.core.mbean.WorkflowStatsMBeanImpl.activate(WorkflowStatsMBeanImpl.java:128)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.apache.felix.scr.impl.helper.BaseMethod.invokeMethod(BaseMethod.java:222)
{noformat}
Apart from that things seem to work fine. I can see two section in status
{noformat}
Apache Sling Scheduler
Status : active
Name : ApacheSlingdefault
ThreadPool: default
Id: Tue_Jul_19_10:54:59_IST_20161637082656
Job : Registered Service.574, class:
org.apache.jackrabbit.oak.jcr.observation.ChangeProcessor$3, concurrent: false,
bundleId: 76, serviceId: 574
Trigger : Trigger 'DEFAULT.Registered Service.574': triggerClass:
'org.quartz.impl.triggers.SimpleTriggerImpl calendar: 'null'
misfireInstruction: 0 nextFireTime: Tue Jul 19 10:55:13 IST 2016
...
Name : ApacheSlingoak
ThreadPool: oak
Id: Tue_Jul_19_10:55:00_IST_20161797561492
Job : Registered Service.269, class:
org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate, concurrent: false,
runOn: [SINGLE], bundleId: 76, serviceId: 269
Trigger : Trigger 'DEFAULT.Registered Service.269': triggerClass:
'org.quartz.impl.triggers.SimpleTriggerImpl calendar: 'null'
misfireInstruction: 0 nextFireTime: Tue Jul 19 10:55:15 IST 2016
Job : Registered Service.266, class:
org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate, concurrent: false,
runOn: [SINGLE], bundleId: 76, serviceId: 266
Trigger : Trigger 'DEFAULT.Registered Service.266': triggerClass:
'org.quartz.impl.triggers.SimpleTriggerImpl calendar: 'null'
misfireInstruction: 0 nextFireTime: Tue Jul 19 10:55:15 IST 2016
{noformat}
> Support different thread pools for scheduled tasks
> --
>
> Key: SLING-5831
> URL: https://issues.apache.org/jira/browse/SLING-5831
> Project: Sling
> Issue Type: Improvement
> Components: Commons
>Reporter: Carsten Ziegeler
>Assignee:
[jira] [Commented] (SLING-5831) Support different thread pools for scheduled tasks
[ https://issues.apache.org/jira/browse/SLING-5831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15381830#comment-15381830 ] Carsten Ziegeler commented on SLING-5831: - I've added a warn log statement in this case > Support different thread pools for scheduled tasks > -- > > Key: SLING-5831 > URL: https://issues.apache.org/jira/browse/SLING-5831 > Project: Sling > Issue Type: Improvement > Components: Commons >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: Commons Scheduler 2.4.16 > > > Right now the scheduler uses a single thread pool. While this thread pool can > be configured, it means that all scheduled tasks share this pool. In order to > prioratize different tasks over others and avoid blocking important jobs > through unimportant once, we could maybe add a configuration property to > select a thread pool name. > If a pool with that name exists, it's used - if not the default is used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-5831) Support different thread pools for scheduled tasks
[ https://issues.apache.org/jira/browse/SLING-5831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15381803#comment-15381803 ] Chetan Mehrotra commented on SLING-5831: bq. Allowing to create an indefinite number of thread pools is maybe not the best idea Fair enough. Lets require explicit config then bq. But I see your point that Sling would not work ootb without a configuration, which is bad. I think it should work. Just that it uses default thread pool (sized to 5 per default). So even if Oak specifies a thread pool name then and such a name is not part of allowed list then it would be using the default pool which is same as it is now. btw can we add some warn or debug logging if a pool name is specified and corresponding pool name is not part of whitelist > Support different thread pools for scheduled tasks > -- > > Key: SLING-5831 > URL: https://issues.apache.org/jira/browse/SLING-5831 > Project: Sling > Issue Type: Improvement > Components: Commons >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: Commons Scheduler 2.4.16 > > > Right now the scheduler uses a single thread pool. While this thread pool can > be configured, it means that all scheduled tasks share this pool. In order to > prioratize different tasks over others and avoid blocking important jobs > through unimportant once, we could maybe add a configuration property to > select a thread pool name. > If a pool with that name exists, it's used - if not the default is used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-5831) Support different thread pools for scheduled tasks
[ https://issues.apache.org/jira/browse/SLING-5831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15381796#comment-15381796 ] Carsten Ziegeler commented on SLING-5831: - I think we (probably I) made a big mistake when the thread pool manager api was created. Allowing to create an indefinite number of thread pools is maybe not the best idea, so I would like to restrict it sooner than later. With the whiteboard scheduling it is pretty easy to mess up. But I see your point that Sling would not work ootb without a configuration, which is bad. So what about we come up with a good thread pool name and have it as a default configuration? > Support different thread pools for scheduled tasks > -- > > Key: SLING-5831 > URL: https://issues.apache.org/jira/browse/SLING-5831 > Project: Sling > Issue Type: Improvement > Components: Commons >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: Commons Scheduler 2.4.16 > > > Right now the scheduler uses a single thread pool. While this thread pool can > be configured, it means that all scheduled tasks share this pool. In order to > prioratize different tasks over others and avoid blocking important jobs > through unimportant once, we could maybe add a configuration property to > select a thread pool name. > If a pool with that name exists, it's used - if not the default is used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-5831) Support different thread pools for scheduled tasks
[ https://issues.apache.org/jira/browse/SLING-5831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15381789#comment-15381789 ] Chetan Mehrotra commented on SLING-5831: bq. I'm not in favour of by default allowing all pool names and giving a way to restrict this. I am fine with providing a way to restrict it. Just suggesting that by default its not restricted. If the sys admin wants he can configure a whitelist on the setup We anyway allow creation of threadpool without any explicit config i.e. just a lookup call with anyname leads to creation of pool. In similar way just having the config present in scheduled job should allow such a pool to be used. Right now to make use of this feature we would always have to modify the Scheduler config. > Support different thread pools for scheduled tasks > -- > > Key: SLING-5831 > URL: https://issues.apache.org/jira/browse/SLING-5831 > Project: Sling > Issue Type: Improvement > Components: Commons >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: Commons Scheduler 2.4.16 > > > Right now the scheduler uses a single thread pool. While this thread pool can > be configured, it means that all scheduled tasks share this pool. In order to > prioratize different tasks over others and avoid blocking important jobs > through unimportant once, we could maybe add a configuration property to > select a thread pool name. > If a pool with that name exists, it's used - if not the default is used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-5831) Support different thread pools for scheduled tasks
[ https://issues.apache.org/jira/browse/SLING-5831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15381783#comment-15381783 ] Carsten Ziegeler commented on SLING-5831: - [~chetanm] Step #1 is optional. If a pool with a name is not configured yet, thread pool manager creates it and uses the default configuration. I'm not in favour of by default allowing all pool names and giving a way to restrict this. This is easily overlooked and easily abused. If your code needs a separate thread pool this is a conscious decision and therefore I think it makes sense that it requires some steps to configure it > Support different thread pools for scheduled tasks > -- > > Key: SLING-5831 > URL: https://issues.apache.org/jira/browse/SLING-5831 > Project: Sling > Issue Type: Improvement > Components: Commons >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: Commons Scheduler 2.4.16 > > > Right now the scheduler uses a single thread pool. While this thread pool can > be configured, it means that all scheduled tasks share this pool. In order to > prioratize different tasks over others and avoid blocking important jobs > through unimportant once, we could maybe add a configuration property to > select a thread pool name. > If a pool with that name exists, it's used - if not the default is used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-5831) Support different thread pools for scheduled tasks
[ https://issues.apache.org/jira/browse/SLING-5831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15381748#comment-15381748 ] Chetan Mehrotra commented on SLING-5831: [~cziegeler] Can we change the default for #1 i.e. by default if any threadpool name is specified then it would be lookedup (and per default threadpool module creates one based on name with some default settings) Have allowedPoolNames by default empty which means that any pool name specified would be valid and enabled. If sys admin see that this is being abused then he can restrict the pools used to specified list. This would ensure that this features get used with only changes done at Oak level (and new scheduler impl) and no extra config step would be required. Otherwise one would have to do this on all setups as we would like that Oak indexing does get dedicated pool > Support different thread pools for scheduled tasks > -- > > Key: SLING-5831 > URL: https://issues.apache.org/jira/browse/SLING-5831 > Project: Sling > Issue Type: Improvement > Components: Commons >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: Commons Scheduler 2.4.16 > > > Right now the scheduler uses a single thread pool. While this thread pool can > be configured, it means that all scheduled tasks share this pool. In order to > prioratize different tasks over others and avoid blocking important jobs > through unimportant once, we could maybe add a configuration property to > select a thread pool name. > If a pool with that name exists, it's used - if not the default is used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-5831) Support different thread pools for scheduled tasks
[ https://issues.apache.org/jira/browse/SLING-5831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15381714#comment-15381714 ] Carsten Ziegeler commented on SLING-5831: - [~chetanm] You should do three things: 1. Create a named thread pool for your tasks using the thread pool module 2. Configure Sling's QuartzScheduler with the new property allowedPoolNames and add the name from 1. to that configuration 3. In your code, add the new property "scheduler.threadPool" with the name of the pool created in 1 > Support different thread pools for scheduled tasks > -- > > Key: SLING-5831 > URL: https://issues.apache.org/jira/browse/SLING-5831 > Project: Sling > Issue Type: Improvement > Components: Commons >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: Commons Scheduler 2.4.16 > > > Right now the scheduler uses a single thread pool. While this thread pool can > be configured, it means that all scheduled tasks share this pool. In order to > prioratize different tasks over others and avoid blocking important jobs > through unimportant once, we could maybe add a configuration property to > select a thread pool name. > If a pool with that name exists, it's used - if not the default is used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-5831) Support different thread pools for scheduled tasks
[
https://issues.apache.org/jira/browse/SLING-5831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15379283#comment-15379283
]
Chetan Mehrotra commented on SLING-5831:
Thanks Carsten for this support!. In Oak we use following approach to use Sling
Scheduler. Can you suggest what change would be required there to make use of
this new feature
{code}
public static Registration scheduleWithFixedDelay(
Whiteboard whiteboard, Runnable runnable, long delayInSeconds,
boolean runOnSingleClusterNode) {
ImmutableMap.Builder builder = ImmutableMap.builder()
.put("scheduler.period", delayInSeconds)
.put("scheduler.concurrent", false);
if (runOnSingleClusterNode) {
//Make use of feature while running in Sling SLING-2979
builder.put("scheduler.runOn", "SINGLE");
}
return whiteboard.register(
Runnable.class, runnable, builder.build());
}
{code}
> Support different thread pools for scheduled tasks
> --
>
> Key: SLING-5831
> URL: https://issues.apache.org/jira/browse/SLING-5831
> Project: Sling
> Issue Type: Improvement
> Components: Commons
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Commons Scheduler 2.4.16
>
>
> Right now the scheduler uses a single thread pool. While this thread pool can
> be configured, it means that all scheduled tasks share this pool. In order to
> prioratize different tasks over others and avoid blocking important jobs
> through unimportant once, we could maybe add a configuration property to
> select a thread pool name.
> If a pool with that name exists, it's used - if not the default is used.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-5831) Support different thread pools for scheduled tasks
[ https://issues.apache.org/jira/browse/SLING-5831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15379267#comment-15379267 ] Carsten Ziegeler commented on SLING-5831: - [~chetanm] I've done a first implementation which creates now the schedulers on demand. To avoid creating endless pools/schedulers, the scheduler is configured with a list of allowed thread pool names. If a pool is not in that list, the job is scheduled using the default pool. > Support different thread pools for scheduled tasks > -- > > Key: SLING-5831 > URL: https://issues.apache.org/jira/browse/SLING-5831 > Project: Sling > Issue Type: Improvement > Components: Commons >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: Commons Scheduler 2.4.16 > > > Right now the scheduler uses a single thread pool. While this thread pool can > be configured, it means that all scheduled tasks share this pool. In order to > prioratize different tasks over others and avoid blocking important jobs > through unimportant once, we could maybe add a configuration property to > select a thread pool name. > If a pool with that name exists, it's used - if not the default is used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-5831) Support different thread pools for scheduled tasks
[ https://issues.apache.org/jira/browse/SLING-5831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15378928#comment-15378928 ] Chetan Mehrotra commented on SLING-5831: That would not be an issue with current implementation. As mentioned at [1] current blockForAvailableThreads would never say its full. So approach should work But going with multiple schedulers would be more cleaner approach and something which does not rely on implementation details [1] http://markmail.org/thread/dgkzt4nnaqh7fa3b > Support different thread pools for scheduled tasks > -- > > Key: SLING-5831 > URL: https://issues.apache.org/jira/browse/SLING-5831 > Project: Sling > Issue Type: Improvement > Components: Commons >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: Commons Scheduler 2.4.16 > > > Right now the scheduler uses a single thread pool. While this thread pool can > be configured, it means that all scheduled tasks share this pool. In order to > prioratize different tasks over others and avoid blocking important jobs > through unimportant once, we could maybe add a configuration property to > select a thread pool name. > If a pool with that name exists, it's used - if not the default is used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-5831) Support different thread pools for scheduled tasks
[ https://issues.apache.org/jira/browse/SLING-5831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15378134#comment-15378134 ] Carsten Ziegeler commented on SLING-5831: - As a first step I've refactored the code and created a SchedulerProxy which is holding the quartz scheduler and the corresponding thread pool. If we agree that this is the way to go, we can simply create a map with those proxies based on the thread pool name > Support different thread pools for scheduled tasks > -- > > Key: SLING-5831 > URL: https://issues.apache.org/jira/browse/SLING-5831 > Project: Sling > Issue Type: Improvement > Components: Commons >Reporter: Carsten Ziegeler > Fix For: Commons Scheduler 2.4.16 > > > Right now the scheduler uses a single thread pool. While this thread pool can > be configured, it means that all scheduled tasks share this pool. In order to > prioratize different tasks over others and avoid blocking important jobs > through unimportant once, we could maybe add a configuration property to > select a thread pool name. > If a pool with that name exists, it's used - if not the default is used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-5831) Support different thread pools for scheduled tasks
[ https://issues.apache.org/jira/browse/SLING-5831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15377348#comment-15377348 ] Carsten Ziegeler commented on SLING-5831: - [~chetanm] I think the above does not work, imagine the default QuartzThreadPool is exhausted, now a job running with a different pool should be scheduled. Quartz can't start it as the QuartzThreadPool is exhausted. I think the only option is to create a scheduler per thread pool that is used > Support different thread pools for scheduled tasks > -- > > Key: SLING-5831 > URL: https://issues.apache.org/jira/browse/SLING-5831 > Project: Sling > Issue Type: Improvement > Components: Commons >Reporter: Carsten Ziegeler > Fix For: Commons Scheduler 2.4.16 > > > Right now the scheduler uses a single thread pool. While this thread pool can > be configured, it means that all scheduled tasks share this pool. In order to > prioratize different tasks over others and avoid blocking important jobs > through unimportant once, we could maybe add a configuration property to > select a thread pool name. > If a pool with that name exists, it's used - if not the default is used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-5831) Support different thread pools for scheduled tasks
[
https://issues.apache.org/jira/browse/SLING-5831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15372393#comment-15372393
]
Chetan Mehrotra commented on SLING-5831:
One way would be to handle this in
{{o.a.s.commons.scheduler.impl.QuartzScheduler.QuartzThreadPool#runInThread}}.
The runnable passed there is an instance of {{JobRunShell}}. Unfortunately it
does not expose {{JobDetail}} directly that would need to be seen. High level
# Client code which register the Runnable in OSGi also specify a new service
property. {{category}} (or poolName). The category is then used to lookup
threadpool name.
# This service property is passed as part of {{JobDataMap}}
# Have this info "somehow" extracted from {{JobDataMap}} in
{{QuartzScheduler.QuartzThreadPool#runInThread}} and then that is used to
lookup the thread pool. If none is present we use the default pool
Things could have been done in a cleaner way if it was possible to provide a
custom {{JobRunShellFactory}} but {{DirectSchedulerFactory}} is tied to
{{StdJobRunShellFactory}}
> Support different thread pools for scheduled tasks
> --
>
> Key: SLING-5831
> URL: https://issues.apache.org/jira/browse/SLING-5831
> Project: Sling
> Issue Type: Improvement
> Components: Commons
>Reporter: Carsten Ziegeler
> Fix For: Commons Scheduler 2.4.16
>
>
> Right now the scheduler uses a single thread pool. While this thread pool can
> be configured, it means that all scheduled tasks share this pool. In order to
> prioratize different tasks over others and avoid blocking important jobs
> through unimportant once, we could maybe add a configuration property to
> select a thread pool name.
> If a pool with that name exists, it's used - if not the default is used.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
