You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@lucene.apache.org by "Erick Erickson (Jira)" <ji...@apache.org> on 2020/05/09 17:53:00 UTC

[jira] [Resolved] (SOLR-10562) TestSolrCLIRunExample failures indicating documents just indexed are not all searchable.

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

Erick Erickson resolved SOLR-10562.
-----------------------------------
    Resolution: Fixed

This test hasn't failed since September of 2019, so I'll close it. Apparently SOLR-11035 and, perhaps, other changes since fixed this.

> TestSolrCLIRunExample failures indicating documents just indexed are not all searchable.
> ----------------------------------------------------------------------------------------
>
>                 Key: SOLR-10562
>                 URL: https://issues.apache.org/jira/browse/SOLR-10562
>             Project: Solr
>          Issue Type: Bug
>    Affects Versions: 6.6, 7.0
>            Reporter: Erick Erickson
>            Assignee: Erick Erickson
>            Priority: Major
>         Attachments: 1_1.res, 1_2.res, 2_1.res, 2_2.res, debug.patch, runcli_12.log
>
>
> I've been beating the heck out of some test cases for fear that
> SOLR-10007 really messed things up and I can get a pretty regular test
> failure for TestSolrCLIRunExample.testInteractiveSolrCloudExample, but
> it doesn't make sense.
> So I went back to a revision _before_ SOLR-10007 and it still fails.
> But the failure is "impossible". I put a bunch of log.error messages
> in and, for experimental purposes a for loop in the test. Here's the
> lines that fail in the original:
> {code}
> for (idx = 0; idx < 10; ++idx) {
>  construct a SolrInputDoc and then:
>   cloudClient.add(SolrInputDoc);
> }
> cloudClient.commit();
> QueryResponse qr = cloudClient.query(new SolrQuery("str_s:a"));
> if (qr.getResults().getNumFound() != numDocs) {
>   fail("Expected "+numDocs+" to be found in the "+collectionName+
>       " collection but only found "+qr.getResults().getNumFound());
> }
> {code}
> If I put the above (not the commit, just the query and the test) in a
> loop and check the query 10 times with a 1 second sleep if the numDocs
> != getNumFound(). Quite regularly I'll see a message in the log file
> that getNumFound() != numDocs, but after a few loops getNumFound() ==
> numDocs and the test succeeds.
> cloudClient is what you'd expect:
> cloudClient = getCloudSolrClient(executor.solrCloudCluster.getZkServer().getZkAddress());
> So unless I'm hallucinating, any tests that rely on
> cloudClient.commit() insuring that all docs sent to the cluster are
> searchable will potentially fail on occasion.
> I looked over the JIRAs briefly and don't see any mentions, of a
> similar problem, but I may have missed it.
> The logging I'm writing from the update handler _seems_ to show it to be doing the right thing. Just late.
> I'll attach some data along with a "patch" which generates the logging information. I also attempted to submit a single batch rather than 10 individual docs and that fails too.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org