[
https://issues.apache.org/jira/browse/SOLR-14374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17074843#comment-17074843
]
David Smiley commented on SOLR-14374:
-------------------------------------
I was just thinking about this more and I wonder if I'm motivated to use an
executor for less than ideal reasons. The real goal/motivation is metrics +
constraining the number of concurrent heavy operation so we don't do too much
of that at once. We don't *need* an executor for that. Metrics are easy to do
by itself, and constraining concurrent operations can be done with a simple
Semaphore. Heck, we could make InstrumentedSemaphore similar to Codahale's
InstrumentedExecutorService. I suppose the advantage of using the existing
executor is because precisely that it already exists.
If hypothetically I introduce metrics/semaphore, I propose I un-instrument the
existing coreLoadExecutor as I think it's better to have enduring metrics for
loading cores over the life of the node instead of simply limiting it to
startup. CC [~ab]
> Use coreLoadExecutor to load all cores; not just startup
> --------------------------------------------------------
>
> Key: SOLR-14374
> URL: https://issues.apache.org/jira/browse/SOLR-14374
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: David Smiley
> Assignee: David Smiley
> Priority: Major
>
> CoreContainer.load() creates coreLoadExecutor (an Executor) to load
> pre-existing cores concurrently -- defaulting to 8 at a time. Then it's
> never used again. However, cores might be loaded in other circumstances: (a)
> creating new cores, (b) "transient" cores, or (c) loadOnStartup=false cores,
> (d) reload cores. By using coreLoadExecutor for all cases, we'll then have
> metrics for core loading that work globally and not just on startup since
> coreLoadExecutor is instrumented already --
> {{CONTAINER.threadPool.coreLoadExecutor}} metrics path.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
