[
https://issues.apache.org/jira/browse/SOLR-4478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13712432#comment-13712432
]
Erick Erickson commented on SOLR-4478:
--------------------------------------
OK, reconstructing an chat exchange:
Sharing the underlying solrconfig objects looks like it's more difficult than I
thought, with some interesting corner cases that would be difficult, i.e ${}
substitutions, resource loader being shared, etc. Also, the individual core
properties are embedded in the Config object, so keeping these separate is
another source of getting code wrong.
Not to mention that the code changes would be more extensive than anyone had
hoped.
At lest the use-case of opening a core and actively using it for a while then
moving on is handled by the lazy/transient core opportunities.
There is historical evidence that a significant amount of CPU resources are
consumed by opening/closing cores 100s of times a second, so that scenario is
still out there.
The net-net is that it's probably not worth the effort right now to really
share the underlying solrConfig object across cores, too many ways to go wrong.
The refactoring that's been done should make this easier if we decide to do it
in the future.
> Allow cores to specify a named config set
> -----------------------------------------
>
> 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
> Assignee: 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
