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:


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());
}

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.

Want me to raise a JIRA or is somebody already looking at it? I can
attach my debug information so you can see the sequence of events. The
messages I'm writing from the update handler _seem_ to be doing the
right thing. Just late.

Hmmm, interestingly the loop that adds documents has cloudClient add
them one at a time. I'm going to see what happens if I change the test
to collect all the docs in a list and send them in a batch instead.

Let me know,
Erick

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to