[
https://issues.apache.org/jira/browse/LUCENE-8963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16922304#comment-16922304
]
Adrien Grand commented on LUCENE-8963:
--------------------------------------
I don't think this would solve any problem? Collectors can only run from a
single thread anyway, and all collectors could have a CollectorManager provided
that there is a way that the results that they produce can be merged?
> Allow Collectors To "Publish" If They Can Be Used In Concurrent Search
> ----------------------------------------------------------------------
>
> Key: LUCENE-8963
> URL: https://issues.apache.org/jira/browse/LUCENE-8963
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Atri Sharma
> Priority: Major
>
> There is an implied assumption today that all we need to run a query
> concurrently is a CollectorManager implementation. While that is true, there
> might be some corner cases where a Collector's semantics do not allow it to
> be concurrently executed (think of ES's aggregates). If a user manages to
> write a CollectorManager with a Collector that is not really concurrent
> friendly, we could end up in an undefined state.
>
> This Jira is more of a rhetorical discussion, and to explore if we should
> allow Collectors to implement an API which simply returns a boolean
> signifying if a Collector is parallel ready or not. The default would be
> true, until a Collector explicitly overrides it?
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
