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