[
https://issues.apache.org/jira/browse/SOLR-4478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13787277#comment-13787277
]
Trey Grainger commented on SOLR-4478:
-------------------------------------
(moving this from my previous e-mail to the solr-dev mailing list)
There are two use-cases that appear broken with the new core auto-discovery
mechanism:
1) *The Core Admin Handler's CREATE command no longer works to create brand new
cores*
(unless you have logged on the box and created the core's directory structure
manually, which largely defeats the purpose of the "CREATE" command). With the
old Solr.xml format, we could spin up as many cores as we wanted to dynamically
with the following command:
http://localhost:8983/solr/admin/cores?action=CREATE&name=newCore1&instanceDir=collection1&dataDir=newCore1/data
...
http://localhost:8983/solr/admin/cores?action=CREATE&name=newCoreN&instanceDir=collection1&dataDir=newCoreN/data
In the new core discovery mode, this exception is now thrown:
Error CREATEing SolrCore 'newCore1': Could not create a new core in
solr/collection1/as another core is already defined there
The exception is being intentionally thrown in CorePropertiesLocator.java
because a core.properties file already exists in solr/collection1 (and only one
can exist per directory).
2) *Having a shared configuration directory (instanceDir) across many cores no
longer works.*
Every core has to have it's own conf/ directory, and this doesn't seem to be
overridable any longer. Previously, it was possible to have many cores share
the same instanceDir (and just override their dataDir for obvious reasons).
Now, it is necessary to copy and paste identical config files for each Solr
core.
I don't know if there's already a current roadmap for fixing this. I saw
https://issues.apache.org/jira/browse/SOLR-4478, which suggested replacing
instanceDir with the ability to specify a named configSet. This solves problem
2, but not problem1 (since you still can't have multiple core.properties files
in the same folder). Based on Erick's comments in the JIRA ticket, it also
sounds like this ticket is also dead at the moment.
There is definitely a need to have a shared config directory - whether that is
through a configSet or an explicit indexDir doesn't matter to me. There's also
a need to be able to dynamically create Solr cores from external systems. I
currently can't upgrade to core auto discovery because it doesn't allow dynamic
core creation. Does anyone have some thoughts on how to best get these
features working again under core autodiscovery? Adding instanceDir to
core.properties seems like an easy solution, but there must be a desire not to
do that or it would probably have already been done.
I'm happy to contribute some time to resolving this if there is agreed upon
path forward.
> Allow cores to specify a named config set in non-SolrCloud mode
> ---------------------------------------------------------------
>
> Key: SOLR-4478
> URL: https://issues.apache.org/jira/browse/SOLR-4478
> Project: Solr
> Issue Type: Improvement
> Affects Versions: 4.2, 5.0
> Reporter: Erick Erickson
> Attachments: SOLR-4478.patch, SOLR-4478.patch
>
>
> Part of moving forward to "the new way", after SOLR-4196 etc... I propose an
> additional parameter specified on the <core> node in solr.xml or as a
> parameter in the "discovery" mode core.properties file, call it configSet,
> where the value provided is a path to a directory, either absolute or
> relative. Really, this is as though you copied the conf directory somewhere
> to be used by more than one core.
> Straw-man: There will be a directory <solr_home>/configsets which will be the
> default. If the configSet parameter is, say, "myconf", then I'd expect a
> directory named "myconf" to exist in <solr_home>/configsets, which would look
> something like
> <solr_home>/configsets/myconf/schema.xml
> solrconfig.xml
> stopwords.txt
> velocity
> velocity/query.vm
> etc.
> If multiple cores used the same configSet, schema, solrconfig etc. would all
> be shared (i.e. shareSchema="true" would be assumed). I don't see a good
> use-case for _not_ sharing schemas, so I don't propose to allow this to be
> turned off. Hmmm, what if shareSchema is explicitly set to false in the
> solr.xml or properties file? I'd guess it should be honored but maybe log a
> warning?
> Mostly I'm putting this up for comments. I know that there are already
> thoughts about how this all should work floating around, so before I start
> any work on this I thought I'd at least get an idea of whether this is the
> way people are thinking about going.
> Configset can be either a relative or absolute path, if relative it's assumed
> to be relative to <solr_home>.
> Thoughts?
--
This message was sent by Atlassian JIRA
(v6.1#6144)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
