[
https://issues.apache.org/jira/browse/SLING-10441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17355102#comment-17355102
]
Stefan Egli commented on SLING-10441:
-------------------------------------
An ExecutorService would be a good option I think. Btw: using a {{ThreadPool}}
might be yet another one actually.
(I guess the only reason for being hesitant to switch to a dedicated scheduler
thread pool is the fact that it only works fine, if the
[allowedPoolNames|https://github.com/apache/sling-org-apache-sling-commons-scheduler/blob/66cb56edf30a863ca825a84c95efb9c3f380918b/src/main/java/org/apache/sling/commons/scheduler/impl/QuartzScheduler.java#L188]
is correctly configured (otherwise it falls back to the default pool). So it's
not enough to update the discovery bundles, the config must also be correctly
adjusted..)
Too many options, might have to roll a dice
> make discovery independent from scheduler thread pools
> ------------------------------------------------------
>
> Key: SLING-10441
> URL: https://issues.apache.org/jira/browse/SLING-10441
> Project: Sling
> Issue Type: Task
> Components: Discovery
> Affects Versions: Discovery Commons 1.0.20, Discovery Impl 1.2.12,
> Discovery Base 2.0.8, Discovery Oak 1.2.30
> Reporter: Stefan Egli
> Assignee: Stefan Egli
> Priority: Major
>
> Currently discovery uses the commons.scheduler for a few but mission critical
> cases. Since the commons.scheduler doesn't guarantee timely execution - eg
> when the corresponding thread pool is full - discovery should become
> independent of commons.scheduler.
> The easiest solution is to spawn {{new Thread}} in those few cases. This
> shouldn't be problematic since these activities are not happening on a high
> frequency and are only short-lived.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
