[
https://issues.apache.org/jira/browse/LUCENE-8963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16922322#comment-16922322
]
Atri Sharma commented on LUCENE-8963:
-------------------------------------
Yeah, I agree.
My only gripe is that in case a collector is not really reducible or has some
semantic constraints against concurrency, we do not provide any defense against
getting into an unknown state.
Maybe it is not an engine problem but more of a user issue – but I wanted to
raise this point and see if we have any thoughts about this.
> 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
