[jira] [Resolved] (SOLR-16587) Solr 9.1.0 last page retrieval error

["Jan Høydahl (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SOLR-16587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Høydahl resolved SOLR-16587.
--------------------------------
    Resolution: Duplicate

Closing as duplicate, as this is definitely same. Likely you will hit the same bug with "offset=100" as you do for "offset=200".

> 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
>         Attachments: Screenshot from 2022-12-13 15-09-00.png, Screenshot from 2022-12-13 15-10-11.png
>
>
> 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-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org