[
https://issues.apache.org/jira/browse/SOLR-13350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16840549#comment-16840549
]
Yonik Seeley commented on SOLR-13350:
-------------------------------------
In general, it seems like an executor for parallel searches would be more
useful at the CoreContainer level. If the executor is per-searcher, then
picking a high enough pool size for good concurrency for a single core means
that one would get way to many threads if one has tons of cores per node (not
that unusual)
We should also audit all Weight classes in Solr for thread safety (if it hasn't
been done yet.) . Relying on existing tests to catch stuff like that won't work
that well for catching race conditions.
> Explore collector managers for multi-threaded search
> ----------------------------------------------------
>
> Key: SOLR-13350
> URL: https://issues.apache.org/jira/browse/SOLR-13350
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Ishan Chattopadhyaya
> Assignee: Ishan Chattopadhyaya
> Priority: Major
> Attachments: SOLR-13350.patch, SOLR-13350.patch, SOLR-13350.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> AFAICT, SolrIndexSearcher can be used only to search all the segments of an
> index in series. However, using CollectorManagers, segments can be searched
> concurrently and result in reduced latency. Opening this issue to explore the
> effectiveness of using CollectorManagers in SolrIndexSearcher from latency
> and throughput perspective.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
