[
https://issues.apache.org/jira/browse/SOLR-350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12562834#action_12562834
]
Hoss Man commented on SOLR-350:
-------------------------------
hey guys ... i'm catching up on some Jira reading and this comment jumped out
at me...
bq. improved code related to configuration wrt absolute/relative locations:
allows core dataDir/instanceDir to be absolute or relative to multicore
(pseudo) instanceDir/dataDir.
(i'm guessing that's what the dataDir option in the <multicore/> tag in Ryan's
example is for?)
this seems like a bad idea to me ... violating the principle of least suprise
and all. it will make the behavior of a solrconfig.xml file dependent on
whether or not it's being used in a multicore context or not.
I'd like to suggest that an aternate approach would be to generalize the
current system property based variable substitution to support arbitrary
key=val pairs specified when the SolrCore is constructed...
* we add new syntax to multicore.xml for declaring "global properties"
* MultiCore converts these global declarations into a SolrParams instance
* we also add syntax to multicore.xml for declaring properties specific to a
core.
* when MultiCore instantiates a core, it uses DefaultSolrParams to let the
specific properties override the global properties *and* to set a special
property containing the name of the core (ie: "solr.core.name")
* if cloning a core is possible (i can't remember) MultiCore would reuse the
SolrParams from the source core, changing only the core name property
(solr.core.name)
* system properties with the same names as properties in multicore.xml would
trump anything from the configs (since they are a run time overrides)
{code}
<multicore adminPath="/admin/multicore" persistent="true" >
<abortOnConfigurationError>true</abortOnConfigurationError>
<requestDispatcher handleSelect="true" >
<requestParsers enableRemoteStreaming="false"
multipartUploadLimitInKB="2048" />
</requestDispatcher>
<property name="alldata.dir">/my/solr/basedir</property>
<property name="magicnumber">32</property>
<!-- core0 gets props above, any other props in it's configs must come from
system props -->
<core name="core0" instanceDir="core0" />
<core name="core1" instanceDir="core1">
<property name="dataDir">foo</property>
</core>
<core name="core111" instanceDir="core1"><!-- note same instanceDir as
above-->
<!-- can reuse exact same instance dir as another core ${solr.core.name}
will be differnet -->
<property name="dataDir">bar</property>
<!-- and now ${dataDir} will be different too -->
</core>
</multicore>
{code}
This would not only give us the ability to have a common ${alldata.dir} for all
cores, but also an easy way to reuse the same solrconfig.xml for multiple cores
and still get subtle changes in behavior -- all while making it transparent
what any one solrconfig.xml will do.
Super powerful -- and (i think) pretty easy to implement... a new optional
SolrParams arg to the SolrCore, SolrConfig, and Config constructors, and
DOMUtil.substituteSystemProperties plus some code in MultiCore to create the
SolrParams (hmm, DOMUtil doesn't have a very friendly method for that yet, not
that big a deal though)
what do you think?
> Manage Multiple SolrCores
> -------------------------
>
> Key: SOLR-350
> URL: https://issues.apache.org/jira/browse/SOLR-350
> Project: Solr
> Issue Type: Improvement
> Affects Versions: 1.3
> Reporter: Ryan McKinley
> Attachments: SOLR-350-MultiCore.patch, SOLR-350-MultiCore.patch,
> SOLR-350-MultiCore.patch, SOLR-350-Naming.patch, SOLR-350-Naming.patch,
> solr-350.patch, solr-350.patch, solr-350.patch, solr-350.patch,
> solr-350.patch, solr-350.patch, solr-350.patch, solr-350.patch
>
>
> In SOLR-215, we enabled support for more then one SolrCore - but there is no
> way to use them yet.
> We need to make some interface to manage, register, modify avaliable SolrCores
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
