OK, belay that. On a whim I decided to look at what happens if I changed things around to use an fq clause. It's apparently not the queryResultCache that's the problem, it's the filterCache.
Raising a JIRA soon. But I'm not sure where things are going wrong, the filterCache stats aren't indicating a problem but the number of returned docs is definitely wrong. Best, Erick On Sat, Aug 29, 2015 at 12:29 PM, Erick Erickson <erickerick...@gmail.com> wrote: > Hmmm, I took a whack at trying to create a unit test for this > and I can't get it to fail. The test works like this > >> index 100 docs >> send a query that exceeds timeAllowed >> check that the stats on the queryResultCache show no inserts >> check that partial results are indicated >> check that the number of docs found < 100 >> re-send the same query with long timeAllowed >> check that there has been a single insert into the queryResultCache >> check that there are still no hits on the queryResultCache >> check that the number of docs found == 100 > > I do see one anomaly, that is after the second call the response > _still_ indicates > partial results, but this isn't quite the same thing. > > Are you sure that some other layer isn't caching things? What do you see if > you look at the admin/plugins-stats/queryResultCache>>hits before and after > the calls? If it's truly the queryResultCache, you should se no > additional insert > for the call that exceeds timeAllowed, and for the call that completes before > timeAllowed expires you should see an additional insert but no increment in > the hit count for that cache. > > Best, > Erick > > On Fri, Aug 28, 2015 at 10:48 PM, Shawn Heisey <apa...@elyograg.org> wrote: >> On 8/28/2015 10:47 PM, William Bell wrote: >>> As we reported, we are having issues with timeAllowed on 5.2.1. If we set a >>> timeAllowed=1 and then run the same query with timeAllowed=30000 we get the >>> # of rows that was returned on the first query. >>> >>> It appears the results are cached when exceeding the timeAllowed, like the >>> results are correct - when they are truncated. >>> >>> SEEMS LIKE A BUG TO ME. >> >> That sounds like a bug to me, too. >> >> Is there any indication in the results the first time that the query was >> aborted before it finished? If Solr can detect that it aborted the >> query, it should not be caching the results. >> >> Thanks, >> Shawn >>
