[
https://issues.apache.org/jira/browse/SOLR-10562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15982084#comment-15982084
]
Erick Erickson commented on SOLR-10562:
---------------------------------------
Nice sleuthing [~shalinmangar]! I can make this happen pretty reliably so if
you want me to beat it up let me know. I'm not sure I'll be able to find time
to work on the code though.
[[email protected]] This may be behind a number of the intermittent test
failures, we'll see if Shalin comes up with a solution.
> CloudSolrClient.commit can return before docs are searchable.
> -------------------------------------------------------------
>
> Key: SOLR-10562
> URL: https://issues.apache.org/jira/browse/SOLR-10562
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Affects Versions: 6.6, master (7.0)
> Reporter: Erick Erickson
> Assignee: Erick Erickson
> 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
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
