lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <>
Subject [jira] [Updated] (SOLR-7171) BaseDistributedSearchTestCase.getSolrXml() not used consistently - multiple divergent ways a JettySolrRunner may be inited
Date Fri, 27 Feb 2015 23:08:04 GMT


Hoss Man updated SOLR-7171:
    Attachment: SOLR-7171.patch

the previous patch broke {{DistributedClusteringComponentTest}} - which is evidently the only
contrib test we have that test distributed queries.

Once i got logs enabled for the test, it was clear thatthe problem was that in the contrib
test, where {{getSolrHome()}} was overridden to point to the contrib test directory with a
collection1 that had all the clustering configs enabled, Solr was failing to init because
there were do directories under the {{coreRootDirectory}} that both had a {{}}
claiming they were {{collection1}} ... there was the _real_ collection1 that the test wanted,
but there was also an empty {{cores}} directory that contained nothing but a {{}}
file (claiming to be {{name=collection1}}.

I spent a while trying to figure out how the hell this was working before my patch, before
finally giving up -- because whatever it was _actually_ doing, it seems pretty clear this
was some kind of mistake -- the file being created was directly in a {{./cores/}}
directory that lookd like it was intended to be the {{coreRootDirectory}} -- except the {{coreRootDirectory}}
was always getting set to be the same as {{getSolrHome()}}.

In any case: here's an updated patch where the (previously) odd {{./cores/}} directory is
no longer created; the (now cloned) {{getSolrHome()}} directory is still used as the {{coreRootDirectory}};
a {{./collection1/}} file is created if and only if it does not exist.

This fixes the problem with {{DistributedClusteringComponentTest}} in a way that also keeps
my {{TestSimpleTrackingShardHandler}} working w/o modifications to either -- so hopefully
it should work for any end-user subclasses as well.

Still hammering on the full test suite, but i'd really appreciate it if [~romseygeek] and
[~erickerickson] could review this since it seems like a lot of this "{{./cores/}} dir as
collection1" weirdness came about as a result of SOLR-6840 (and perhaps SOLR-6902? ... not

> BaseDistributedSearchTestCase.getSolrXml() not used consistently - multiple divergent
ways a JettySolrRunner may be inited
> --------------------------------------------------------------------------------------------------------------------------
>                 Key: SOLR-7171
>                 URL:
>             Project: Solr
>          Issue Type: Bug
>            Reporter: Hoss Man
>         Attachments: SOLR-7171.patch, SOLR-7171.patch
> As part of SOLR-6349, i wanted to take advantage of the new features in SOLR-7147 to
inspect shard requests in TestDistributedSearch, but even though i added a proper override
of getSolrXml...
> {code}
>   @Override
>   protected String getSolrXml() {
>     return "solr-trackingshardhandler.xml"; 
>   }
> {code}
> ...that value was being ignored, and i was never getting an instance of TrackingShardHandlerFactory.
> I poked around a bit and confirmed that getSolrXml() is used by "setupJettySolrHome(File)"
but that method is never called by BaseDistributedSearchTestCase - it's only called in framework
subclasses like AbstractDistribZkTestBase and AbstractFullDistribZkTestBase.  Instead, for
simple subclasses of BaseDistributedSearchTestCase the jetty instances seem to be coming from
> ----
> I don't really understand why there are so many diff ways for a shard instance to be
inited, and presumably that should be refactored? .. but a more immediate concern is that
subclasses of BaseDistributedSearchTestCase which attempt to override the solr.xml file used
can't (unless they are actually a subclass of AbstractDistribZkTestBase of AbstractFullDistribZkTestBase)

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message