[
https://issues.apache.org/jira/browse/SOLR-4662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13619872#comment-13619872
]
Erick Erickson commented on SOLR-4662:
--------------------------------------
Hmmmm. Point taken about not exposing a pluggable version yet, now that you
mention it that seems premature. Hardening all that before exposing something
we then have to support makes sense. We can still program to the interface I
mentioned as much as possible to make that easier in future but no big deal
either way.
<1> is done.
<2> OK, what does that look like? Is this just a simple transformation like
<solr>
<solrConfigFactory name="solrConfigFactory" clase="SolrConfigFactory">
<str name="persistent">${solr.xml.persist:false}</str>
<str name="adminPath">/admin/cores</str>
<str name="defaultCoreName">collection1</str>
<str name="host">127.0.0.1</str>
<str name="hostPort">${hostPort:8983}</str>
<str name="hostContext">${hostContext:solr}</str>
<str name="shareSchema">${shareSchema:false}</str>
<shardHandlerFactory name="shardHandlerFactory"
class="HttpShardHandlerFactory">
<int name="socketTimeout">${socketTimeout:120000}</int>
<int name="connTimeout">${connTimeout:15000}</int>
</shardHandlerFactory>
<str name="zkClientTimeout">${solr.zkclienttimeout:30000}</str>
<str name="numShards">${numShards:3}</str>
<str name="distribUpdateConnTimeout">${distribUpdateConnTimeout:15000}</str>
<str name="distribUpdateSoTimeout">${distribUpdateSoTimeout:120000}</str>
</solrConfigFactory>
</solr>
This form doesn't allow cores to be here at all. Is there any necessity to have
a factory here or are you thinking these should just be child nodes of <solr>?
Would shardHandlerFactory be inside or outside the new factory? As you can
tell, how all this fits together is something of a mystery to me. But having a
solrConfigFactory node as the immediate child of <solr> and encompassing all
the rest would allow easy detection of old -vs- new style XML. Adding a version
attribute to the <solr> tag seems possible too, but I don't really like that, I
think there's less user-level maintenance if we use solrConfigFactory,
implementing up different handlers for different versions if/when we change
again, which should be very rare.
<3> On that note, it's not clear to me we need solr.xml at all in "true cloud
mode". In the absence of solr.xml but presence of zkHost, just get everything
from ZK. Look, you know how ZK-ignorant I am, be gentle <G>. The rest of the
time, anything you could possibly want from solr.xml that wasn't present, ask
ZK for it and use defaults if neither source had it. By "not present", that
means neither in the solr.xml file nor as a sysprop. Along the way removing
DEF_SOLR_XML from ConfigSolrXml would be a Good Thing maybe.
> Finalize what we're going to do with solr.xml, auto-discovery, config sets.
> ---------------------------------------------------------------------------
>
> Key: SOLR-4662
> URL: https://issues.apache.org/jira/browse/SOLR-4662
> Project: Solr
> Issue Type: Improvement
> Affects Versions: 4.3, 5.0
> Reporter: Erick Erickson
> Assignee: Erick Erickson
> Priority: Blocker
>
> Spinoff from SOLR-4615, breaking it out here so we can address the changes in
> pieces.
--
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: [email protected]
For additional commands, e-mail: [email protected]
