[
https://issues.apache.org/jira/browse/SOLR-7171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
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 {{core.properties}} 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
{{core.properties}} 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 core.properties 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/core.properties}}
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 certain)
> BaseDistributedSearchTestCase.getSolrXml() not used consistently - multiple
> divergent ways a JettySolrRunner may be inited
> --------------------------------------------------------------------------------------------------------------------------
>
> Key: SOLR-7171
> URL: https://issues.apache.org/jira/browse/SOLR-7171
> 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 createServers(int)
> ----
> 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
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
