[
https://issues.apache.org/jira/browse/SOLR-8658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson updated SOLR-8658:
---------------------------------
Attachment: SOLR-8658.patch
200 runs of this test case and this error did not recur (without this patch).
I'm guessing that it requires a slower machine to reproduce the assumed race
condition. So I don't see any other choice than to commit this test fix and see
if it happens again.
I'll keep this JIRA open for a day or two and then close it if we don't see the
problem again.
I don't think this really requires a CHANGES.txt entry so if we package up 6.0
and 5.5
> Fix test failure introduced in SOLR-8651
> ----------------------------------------
>
> Key: SOLR-8658
> URL: https://issues.apache.org/jira/browse/SOLR-8658
> Project: Solr
> Issue Type: Bug
> Reporter: Erick Erickson
> Assignee: Erick Erickson
> Attachments: SOLR-8658.patch
>
>
> OK, I think I've found a possible reason. The waitForDocCount method waits
> until a response comes back with the, well, expected doc counts. But then it
> drops out of the wait loop the first time a query works.
> But then it goes out to each and every node and re-issues the request. This
> looks to be a 2-shard, 2-replica situation. So here's the theory: the second
> node hasn't yet opened a new searcher. So the wait loop is satisfied by, say,
> node2 but the test later looks at node4 (both for shard2) which hasn't
> completed opening a searcher yet so it fails.
> I could not get this to fail locally in 20 runs. So I'll beast the unchanged
> version some more to see but meanwhile commit this change which I think is
> more correct anyway and monitor.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
