[
https://issues.apache.org/jira/browse/SLING-10441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17354941#comment-17354941
]
Stefan Egli commented on SLING-10441:
-------------------------------------
[~rombert], thx for commenting!
Ideally we'd be able to stick with using scheduler, I agree.
The problem we currently have is that discovery is using the default thread
pool - and discovery is not the only one - in fact, anyone can use the default
thread pool and occupy those threads for an unspecified amount of time (there
is nothing in place that guarantees timely scheduler execution). This results
in situations where the expectation is that a scheduled task is executed, say
in 3 seconds, but actually it gets executed in 30min or 60min or "never". And
that causes headaches and issues.
One alternative would be to configure a separate thread pool for discovery.
That's in fact what was recently discussed. However, I believe that using a
dedicated pool is also somewhat waste of resource, as those threads are used
only very irregularly and only for a small amount of time (basically only
whenever something changes in the topology). Also, there are only 2
places/tasks in discovery where we would use it.
Another alternative would be to use java.util.Timer - but afaics that would
also be suboptimal as that also occupies a thread permanently (assuming sharing
the Timer within discovery - which additionally also requires passing around
that object quite a bit, ie more code changes).
So creating raw threads seems indeed raw but reliable and efficient.
But there's certainly many different ways to solve this and it is not ideal
that raw Threads are "required" here...
> 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)
