[
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
here's a patch i'm currently hammering on ... doesn't completley eliminate all
the code/logic duplication, but at least gets us consistently using
getSolrXml() (as far as i can tell)
Part of making this work, was to change {{createControlJetty()}} and
{{createServers(int numShards)}} to clone the {{getSolrHome()}} dir ...
previously (if you subclassed BaseDistributedSearchTestCase) these methods
would just re-use the same {{getSolrHome()}} dir for all the jetty instances,
and only override the cores & data dirs.
Not sure if folks have any strong opinion against this? it seems like a "fix"
to the previous awkward hoops, and makes these simple distrib test work more
like the cloud tests .. but it would certainly be _possible_ to add more
awkwards hoops to only clone {{getSolrHome()}} in the event that we need to
override the solr.xml.
> 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
>
>
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
