lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pulkit Singhal <>
Subject Re: Solr Cloud - is replication really a feature on the trunk?
Date Sat, 10 Sep 2011 16:59:09 GMT
Yes now I'm sure that
a) collection="blah" in solr.xml, and
b) -Dcollection.configName="myconf" at cmd line
actually fill in values for two very different fields.

Here's why I say so:

Example config # 1:
<core name="master1" instanceDir="." shard="shard1" collection="scaleDeep"/>

Results in:
/collections (v=6 children=1)
          scaleDeep (v=0 children=1) "configName=myconf"

Example config # 2:
Results in:
/collections (v=6 children=1)
          scaleDeep (v=0 children=1) "configName=scaleDeep"

What do you think about that? I maybe mis-interpreting the resutls so
pleaase pelase feel free to set me straight on this.

Also it would be nice if I knew the code well enough to just look @ it
and give an authoritative answer. Does anyone have that kind of
expertise? Reverse-engineering is getting a bit mundane.

- Pulkit

On Sat, Sep 10, 2011 at 11:43 AM, Pulkit Singhal
<> wrote:
> 1s of all, thanks everyone, your expertise and time is much appreciated.
> @Jamie:
> Great suggestion, I just have one small objection to it ... I wouldn't
> want to mix the core's name with the collection's configName. Wouldn't
> you also want to keep the two separate for clarity? What do you think
> about that?
> @Yury:
> Overall what you said makes sense and I'll roll with it. But FYI,
> through experimentation I found out that collection="myconf" does not
> become the value for configName when I inspect ZooKeeper.jsp, here's
> an example of what shows up if I setup the solr.xml file but don't say
> anything in the cmd line startup:
> myconf (v=0 children=1) "configName=configuration1"
> But perhaps that's exactly what you are trying to warn me about. I'll
> experiment more and get back.
> - Pulkit
> On Fri, Sep 9, 2011 at 10:17 PM, Jamie Johnson <> wrote:
>> as a note you could change out the values in solr.xml to be as follows
>> and pull these values from System Properties.
>>  <cores adminPath="/admin/cores" defaultCoreName="${collection.configName}">
>>    <core name="${collection.configName}" instanceDir="." shard="${shard}"/>
>>  </cores>
>> unless someone says otherwise, but the quick tests I've run seem to
>> work perfectly well with this setup.
>> 2011/9/9 Yury Kats <>:
>>> On 9/9/2011 6:54 PM, Pulkit Singhal wrote:
>>>> Thanks Again.
>>>> Another question:
>>>> My solr.xml has:
>>>>   <cores adminPath="/admin/cores" defaultCoreName="master1">
>>>>     <core name="master1" instanceDir="." shard="shard1" collection="myconf"/>
>>>>   </cores>
>>>> And I omitted -Dcollection.configName=myconf from the startup command
>>>> because I felt that specifying collection="myconf" should take care of
>>>> that:
>>>> cd /trunk/solr/example
>>>> java -Dbootstrap_confdir=./solr/conf -Dslave=disabled -DzkRun -jar start.jar
>>> With this you are telling ZK to bootstrap a collection with content of specific
>>> files, but you don't tell what collection that should be.
>>> Hence you want collection.configName parameter, and you want
>>> solr.xml to reference the same name in 'collection' attribute for the cores,
>>> so that SolrCloud knows where to pull configuration for that core from.

View raw message