[ 
https://issues.apache.org/jira/browse/SOLR-18309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18097924#comment-18097924
 ] 

Chris M. Hostetter commented on SOLR-18309:
-------------------------------------------

To be clear: any "per-request" code path in Solr that has expensive loops is a 
worth while candidate for consideration of explicit {{QueryLimit}} checks – but 
if those loops are doing anything index related (like looping over Postings, 
Terms, DocValues, etc...) then Kevin is correct: the changes in SOLR-17182 
should make that a non-issue in Solr 10 (or if you explicitly set 
{{solr.useExitableDirectoryReader=true}} in Solr >= 9.9.1 - see SOLR-17831)

> 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
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to