Thanks! I went on using AbstractFullDistribZkTestBase and for some tests i circumvent the control core. I do sometimes get a recovery time out when starting up the tests. I have set the time out to 30 seconds, just like many other tests that extends AbstractFullDistribZkTestBase. Any thoughts on that?
Issue created: https://issues.apache.org/jira/browse/SOLR-8018 -----Original message----- > From:Chris Hostetter <hossman_luc...@fucit.org> > Sent: Saturday 5th September 2015 2:23 > To: solr-user@lucene.apache.org > Subject: RE: Trouble making tests with BaseDistributedSearchTestCase > > : Strange enough, the following code gives different errors: > : > : assertQ( > > I'm not sure what exactly assertQ will do in a distributed test like this > ... probably nothing good. you'll almost certainly want to stick with > the distributed indexDoc() and query* methods and avoid assertU and > assertQ > > > : [TEST-TestComponent.test-seed#[EA2ED1E118114486]] ERROR > org.apache.solr.SolrTestCaseJ4 - REQUEST FAILED: > xpath=//result/doc[1]/str[@name='id'][.='1'] > : xml response was: <?xml version="1.0" encoding="UTF-8"?> > ... > : <result name="response" numFound="0" start="0"> > : </result> > > ...i'm guessing that's because assertQ is (probably) querying the "local" > core from the TestHarness, not any of the distributed cores setup by > BaseDistributedSearchTestCase and your docs didn't get indexed there. > > : And, when i forcfully add distrib=true, i get a NPE in SearchHandler! > > which is probably becaues since you (manually) added the debug param, but > didn't add a list of shards to query, you triggered some slopy code in > SearchHandler that should be giving you a nice error about shards not > being specified. (i bet you can manually reproduce this in a single-node > solr setup by adding distrib=true to any query thta doesn't have a > "shards" param, if so please file a bug that it should produce a sane > error message) > > if you use something like BaseDistributedSearchTestCase.query on the other > hand, it takes care of adding hte correct distrib related request > params for the shards it creates under the covers. > > (allthough at this point, in general, i would strongly suggest that you > instead consider using AbstractFullDistribZkTestBase instead of > BaseDistributedSearchTestCase -- assuming of course that your goal is good > tests of how some distributed queries behave in a modern solr cloud setup. > if your goal is to test solr under manual sharding/distributed queries, > BaseDistributedSearchTestCase still makes sense.) > > > As to your first question (which applies to both old school and > cloud/zk related tests)... > > : > Executing the above text either results in a: IOException occured when > talking to server at: https://127.0.0.1:44761//collection1 > > That might be due ot a timing issue of the servers not completley starting > up before you start sending requests to them? not really sure ... would > need to see the logs. > > : > Or it fails with a curous error: .response.maxScore:1.0!=null > : > > : > The score correctly changes according to whatever value i set for > parameter q. > > that has to do with teh way the BaseDistributedSearchTestCase plumbing > tries to help ensure that a distribute query returns the same results as a > single shard query by "diffing" the responses (note: this is why > BaseDistributedSearchTestCase.indexDoc adds your doc to both a random > shard *and* to a "control collection"). But there are some legacy quirks > about how things like "maxScore" are handled: notably SOLR-6612 > (historically, because of the possibility of filter optimizations, solr > only kept track of the scores if it needed to. in single core, this was > if you asked for "fl=score,..." but in a distributed query it might also > compute scores (and maxScore) if you are sorting on scores (which is the > default) > > they way to indicate that you don't want BaseDistributedSearchTestCase's > response diff checking to freak out over the max score is using the > (horribly undocumented) "handle" feature... > > handle.put("maxScore", SKIPVAL); > > ...that's not the default in all tests because it could hide errors in > situations where tests *are* expecting the maxScore to be the same. > > > the same mechanism can be used to ignore things like the _version_ > field, or timestamp fields which are virtually garunteed not to be the > same between two differnet collections. (see uses of the "handle" Map in > existing test cases for examples). > > > > -Hoss > http://www.lucidworks.com/ >
