[
https://issues.apache.org/jira/browse/SLING-10441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17355000#comment-17355000
]
Robert Munteanu commented on SLING-10441:
-----------------------------------------
An executor service backed by a single thread or a dynamically sized thread
pool should not be problematic. We should make sure that we clean the resources
properly though.
I still wonder whether it isn't worth to configure a dedicated thread pool in
the commons scheduler with one thread - that should not have a huge impact,
especially since deployments probably oversize their HTTP worker thread pool
(jetty).
If we are worried about the runtime impact, I think the pool size configuration
can be tweaked, e.g. :
- min thread size: 0
- max thread size: 1
- keep alive time: 60,000 ( milliseconds )
> 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)
