[
https://issues.apache.org/jira/browse/SOLR-3613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13411339#comment-13411339
]
Jan Høydahl commented on SOLR-3613:
-----------------------------------
Do we want to allow for people to deploy multiple instances of Solr webapp in
same AppServer?
If so, each webapp should have the chance of defining its own name space for
JAVA OPTS. The ${} substitutions in solrconfig.xml makes this is doable
already. But the SolrCloud ones are hardcoded?. A way to make them user
configurable is to allow them in {{solr.xml}}, not so much for users to edit,
but to define the (default) option names:
{code}
<cloudOptions>
<zkRun>${solr.zkRun:false}</zkRun>
<bootstrapConfdir>${solr.bootstrapConfdir}</bootstrapConfdir>
<collectionConfigName>${solr.collectionConfigName}</collectionConfigName>
<numShards>${solr.numShards}</numShards>
<zkHost>${solr.zkHost}</zkHost>
</cloudOptions>
{code}
The only option which is hard to define a name for up front is
{{solr.solr.home}} (which has a confusing name btw). Would it be an idea to
allow each webapp to have its own solr-home based on the name of the context,
i.e. if you deploy {{solr1.war}} and {{solr2.war}} to same appserver, you could
say {{-Dsolr1.solr.home=/solr1 -Dsolr2.solr.home=/solr2}}. The old
{{-Dsolr.solr.home}} could be a fallback/default if no specific home is given?
This one perhaps warrants its own JIRA.
> Namespace Solr's JAVA OPTIONS
> -----------------------------
>
> Key: SOLR-3613
> URL: https://issues.apache.org/jira/browse/SOLR-3613
> Project: Solr
> Issue Type: Improvement
> Affects Versions: 4.0-ALPHA
> Reporter: Jan Høydahl
> Fix For: 4.0
>
>
> Solr being a web-app, should play nicely in a setting where users deploy it
> on a shared appServer.
> To this regard Solr's JAVA_OPTS should be properly name spaced, both to avoid
> name clashes and for clarity when reading your appserver startup script. We
> currently do that with most: {{solr.solr.home, solr.data.dir,
> solr.abortOnConfigurationError, solr.directoryFactory,
> solr.clustering.enabled, solr.velocity.enabled etc}}, but for some opts we
> fail to do so.
> Before release of 4.0 we should make sure to clean this up.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
