[
https://issues.apache.org/jira/browse/SOLR-18309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18137997#comment-18137997
]
Jason Gerlowski commented on SOLR-18309:
----------------------------------------
bq. is this happening with `-Dsolr.useExitableDirectoryReader=true`
Kevin was spot on - we had not configured that sysprop for this cluster and so
were getting the "default" 9.x behavior. Turning the sysprop on has resolved
this for us. I'm going to close this out accordingly. Thanks guys!
> Query limits should apply to expensive-to-create scorers
> --------------------------------------------------------
>
> Key: SOLR-18309
> URL: https://issues.apache.org/jira/browse/SOLR-18309
> Project: Solr
> Issue Type: Improvement
> Components: Query Limits
> Affects Versions: main(11.0)
> Reporter: Jason Gerlowski
> Priority: Major
>
> Solr's timeAllowed enforcement relies on wrapping the BulkScorer returned by
> Weight.bulkScorer()/scorer() in Lucene's TimeLimitingBulkScorer. This
> wrapping class checks the deadline periodically while documents are actually
> being scored and collected.
> This is sufficient in most cases. But it leaves a gap: short-circuiting can
> only be done after the scorer has been created. This is a problem for
> queries such as "join" or "graph", where scorer-creation itself involves a
> ton of work, issuing sub-requests, etc. None of this scorer-creation work is
> subject to timeAllowed and as a result (e.g.) join queries regularly run
> waaaay over their timeAllowed or other query limits.
> We should find a way to make scorer-creation itself subject to query limits,
> if possible. Or alternatively, rework these query implementations so that
> scorer-creation is a cheaper operation.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
