lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erick Erickson (JIRA)" <>
Subject [jira] [Updated] (SOLR-8658) Fix test failure introduced in SOLR-8651
Date Tue, 09 Feb 2016 03:46:18 GMT


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:
>             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

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message