You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Hoss Man (JIRA)" <ji...@apache.org> on 2016/04/16 01:34:25 UTC
[jira] [Commented] (SOLR-8999) MiniSolrCloudCluster should support
starting a cluster w/existing zk data
[ https://issues.apache.org/jira/browse/SOLR-8999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15243849#comment-15243849 ]
Hoss Man commented on SOLR-8999:
--------------------------------
inspired by this thread...
* http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201604.mbox/%3C7F050C0F16DD934F8599EB5DAE2690350160CA5923@WAYNE.lan.gossinteractive.com%3E
* http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201604.mbox/%3C57114872.7020203@elyograg.org%3E
> MiniSolrCloudCluster should support starting a cluster w/existing zk data
> -------------------------------------------------------------------------
>
> Key: SOLR-8999
> URL: https://issues.apache.org/jira/browse/SOLR-8999
> Project: Solr
> Issue Type: Improvement
> Reporter: Hoss Man
>
> In Solr tests, we always start with a completely pristine tmp directories for each test to use, and all of our existing MiniSolrCloudClusters expect that and MiniSolrCloudCluster creates everything it needs.
> But for Solr clients, that want to write tests using MiniSolrCloudCluster to test their own code, MiniSolrCloudCluster can currently fail in confusing ways if they re-use the "baseDir" in multiple tests runs.
> At a minimum, if MiniSolrCloudCluster is going to expect baseDir to always be empty on construction, then we should document this and assert it in the constructor.
> But it seems to me that it might also be useful if it were _possible_ (even if not the default behavior) to spin up a MiniSolrCloudCluster pointing at an existing baseDir that already had zk server data and existing solr instanceDirs and verify that everything could be started up after a previous total shutdown.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org