Hello.

Was looking at 
https://github.com/apache/lucene-solr/blob/trunk/solr/core/src/java/org/apache/solr/search/SolrIndexSearcher.java
 code to better understand the various getDoc... methods and how collectors are 
combined.

In the scenario outlined below, the second run's timeAllowed parameter is 
unexpectedly ignored. Could this be intentionally so somehow (q vs. fq 
processing?, Collector vs. LeafCollector?, DocList vs. DocSet?), or is it an 
edge-case bug?

Regards,

Christine

---------------------------

solrconfig characteristics:
 * a queryResultsCache is configured
 * no filterCache is configured

query characteristics:
 * q parameter present
 * at least one fq parameter present
 * sort parameter present (and does not require the score field)
 * GET_DOCSET flag is set e.g. via the StatsComponent i.e. stats=true parameter

runtime characteristics:
 * first run of the query gets a queryResultsCache-miss and respects timeAllowed
 * second run gets a queryResultsCache-hit and ignores timeAllowed (but still
   makes use of the lucene IndexSearcher)

code path execution details (first run):
* SolrIndexSearcher.search calls getDocListC
* getDocListC called queryResultCache.get which found nothing
* getDocListC calls getDocListAndSetNC
* getDocListAndSetNC calls buildAndRunCollectorChain
* buildAndRunCollectorChain constructs TimeLimitingCollector

code path execution details (second run):
* SolrIndexSearcher.search calls getDocListC
* getDocListC called queryResultCache.get which found something
* getDocListC calls getDocSet(List<Query> queries)
* getDocSet(List<Query> queries) iterates over IndexSearcher.leafContexts

Reply via email to