[ https://issues.apache.org/jira/browse/SLING-10441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17355117#comment-17355117 ]
Bertrand Delacretaz commented on SLING-10441: --------------------------------------------- bq. it only works fine, if the allowedPoolNames is correctly configured (otherwise it falls back to the default pool).. I suppose you can detect that problem by checking the name of the {{ThreadPool}} that's returned? If that allows you to fail loudly if the configuration is wrong, I think that's acceptable. > 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)