lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erick Erickson (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-4662) Finalize what we're going to do with solr.xml, auto-discovery, config sets.
Date Tue, 02 Apr 2013 14:49:16 GMT

    [ 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message