[
https://issues.apache.org/jira/browse/SOLR-16587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17646592#comment-17646592
]
Jan Høydahl commented on SOLR-16587:
------------------------------------
Hi,
Can you also try to make a minimal reproduction script so we can check it?
E.g a set of cURL commands that first push some docs then triggers the bug?
> Solr 9.1.0 last page retrieval error
> ------------------------------------
>
> Key: SOLR-16587
> URL: https://issues.apache.org/jira/browse/SOLR-16587
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: search
> Environment: Solr 9.1.0
> Search with wildcard query **:* (all match) and reading pages without cursor
> until last page*
> Reporter: Andrei Minin
> Priority: Major
>
> When searching with offset, last page fails by internal assert.
> For example there are 210 documents in index matching criteria and I am
> reading documents using page size =100; 3rd page with range 200 to 300 fails.
> Same unit test runs OK on Solr 8.11 and 9.0.0
> Debugging details:
> class org.apache.solr.search.SolrIndexSearcher method
> {color:#cc7832}private void
> {color}{color:#ffc66d}getDocListC{color}(QueryResult qr{color:#cc7832},
> {color}QueryCommand cmd)
> receives command
> cmd = \{QueryCommand@12109}
> query = \{MatchAllDocsQuery@12121} "*:*"
> queryID = null
> isQueryCancellable = false
> filterList = null
> filter = null
> sort = null
> offset = 200
> len = 200
> supersetMaxDoc = 220
> flags = 0
> timeAllowed = -1
> minExactCount = 2147483647
> cursorMark = null
> On line 1650:
> out.docList = constantScoreDocList(cmd.getOffset(), cmd.getLen(), out.docSet);
> docList created with 10 documents (correct):
> out.docList = \{DocSlice@12126}
> offset = 0
> len = 10
> docs = \{int[10]@12129} [200, 201, 202, 203, 204, 205, 206, 207, 208, 209]
> scores = null
> matches = 210
> matchesRelation = \{TotalHits$Relation@12078} "EQUAL_TO"
> maxScore = 0.0
> ramBytesUsed = 112
> But on line 1687 it is converted to null because cmd offset (200) and lenght
> (200) applied to this 10 documents list (thru reassigning superset):
> / Kludge...
> // we can't use DocSlice.subset, even though it should be an identity op
> // because it gets confused by situations where there are lots of
> matches, but
> // less docs in the slice then were requested, (due to the cursor)
> // so we have to short circuit the call.
> // None of which is really a problem since we can't use caching with
> // cursors anyway, but it still looks weird to have to special case this
> // behavior based on this condition - hence the long explanation.
> superset = out.docList;
> out.docList = superset.subset(cmd.getOffset(), cmd.getLen());
> As result, null docList returned from method (instead of 10 documents list)
> and failed later in class org.apache.solr.response.BasicResultContext on
> assert on line 39:
> {color:#cc7832}assert {color}docList != {color:#cc7832}null;{color}
> In my opition, there is an error on line 1688 in class SolrIndexSearcher:
> out.docList = superset.subset(cmd.getOffset(), cmd.getLen());
> this line shouldn't be called or called with different parameters.
> Honestly I don't understand logic of this line, what is the reason for
> recursive subset call?
> 2 lines can be presented as:
> out.docList = out.docList.subset(cmd.getOffset(), cmd.getLen());
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
