[
https://issues.apache.org/jira/browse/SOLR-10048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15843557#comment-15843557
]
Hoss Man commented on SOLR-10048:
---------------------------------
I'm sorry, I was confusingly imprecise before...
bq. ... which means the order is non-deterministic (and practically speaking
winds up depending on the on disk ordering of the docs).
...what i should have said was: ... Which means the default sort is by {{score
desc}} w/o any secondary sort -- but since the query is {{\*:\*}} all docs
(should) score identically, so the effective sort is non-deterministic ...
I'm not sure what might have changed between 6.3 and 6.4 to cause this test to
only start failing recently (perhaps something change in the shard querying
logic to improve the randomized distribution of sub-requests?) but the bottom
line is that w/o a deterministic sort, Solr has _never_ guaranteed consistent
ordering between multiple requests.
> Distributed result set paging sometimes yields incorrect results
> ----------------------------------------------------------------
>
> Key: SOLR-10048
> URL: https://issues.apache.org/jira/browse/SOLR-10048
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SearchComponents - other
> Affects Versions: 6.4
> Reporter: Markus Jelsma
> Priority: Critical
> Fix For: 6.4.1, master (7.0)
>
> Attachments: DistributedPagedQueryComponentTest.java
>
>
> This bug appeared in 6.4 and i spotted it yesterday when i upgraded a my
> project. It has, amongst others,an extension of QueryComponent, its unit test
> failed, but never in any predictable way and always in another spot.
> The test is very straightforward, it indexes a bunch of silly documents and
> then executes a series of getAll() queries. An array of ids is collected and
> stored for comparison. Then, the same query is executed again but it pages
> through the entire result set.
> It then compares ids, the id at position N must be the same as id NUM_PAGE *
> PAGE_SIZE + M (where M is the position of the result in the paged set). The
> comparison sometimes failes.
> I'll attach the test for 6.4 shortly. If it passes, just try it again (or
> increase maxDocs). It can pass over ten times in a row, but it can also fail
> ten times in a row.
> You should see this if it fails, but probably with different values for
> expected and actual. Below was a few minutes ago, now i can't seem to
> reproduce it anymore.
> {code}
> [junit4] FAILURE 25.1s |
> DistributedPagedQueryComponentTest.testTheCrazyPager <<<
> [junit4] > Throwable #1: java.lang.AssertionError: ids misaligned
> expected:<406> but was:<811>
> [junit4] > at
> __randomizedtesting.SeedInfo.seed([97A7F02D1E4ACF75:7493130F03129E6D]:0)
> [junit4] > at
> org.apache.solr.handler.component.DistributedPagedQueryComponentTest.testTheCrazyPager(DistributedPagedQueryComponentTest.java:83)
> [junit4] > at
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
> [junit4] > at
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
> [junit4] > at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
