You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Chris Rogers <ch...@bodleian.ox.ac.uk> on 2017/02/22 11:16:07 UTC

Problem managing Solr configsets on Zookeeper

Hi all,

I’ve got a Zookeeper (3.4.8) / Solrcloud (6.4.0) setup with two nodes.

I’ve successfully uploaded a collection through one of the Solr nodes:

~~~
bin/solr create -c tolkien -d  tolkien_config -s 2 -rf 2
~~~

I’ve then changed the schema.xml in the config set for this collection (in the /server/solr/configsets/ folder), and used the upconfig zk command to upload it:

~~~
bin/solr zk upconfig -z 172.28.128.9:2181 -n tolkien_config -d /home/bodl-tei-svc/solr-6.4.0/server/solr/configsets/tolkien_config
~~~

I’ve then used the collections API to reload the collections. I’ve run this command for both Solr nodes:

~~~
http://localhost:8983/solr/admin/collections?action=RELOAD&name=tolkien
~~~

All these commands appear to execute successfully. I can confirm that the config is successfully uploaded to Zookeeper, as the downconfig command returns the correct files.

HOWEVER, the content of the Schema UI in the Solr admin does not change. Fields I had removed were still there, and fields added were not.

I then decided to delete the collection entirely, and recreate a new collection with the new schema, but the schema for this new collection remains the same as the old collection!

It’s as if the old config has been cached somewhere or something…

Am I missing a stage or command here?

Many thanks,
Chris

--
Chris Rogers
Digital Projects Manager
Bodleian Digital Library Systems and Services
chris.rogers@bodleian.ox.ac.uk

Re: Problem managing Solr configsets on Zookeeper

Posted by Erick Erickson <er...@gmail.com>.
Shawn's nailed it. I wanted to add that in 6.4 there are additional
commands in bin/solr to explore ZK, e.g.
"ls" which also has a recurse option.

Erick

On Wed, Feb 22, 2017 at 8:15 AM, Shawn Heisey <ap...@elyograg.org> wrote:
> On 2/22/2017 8:25 AM, Chris Rogers wrote:
>> … as uploaded with upconfig. However, in the /solr directory we have a
>> second /configs folder with the old schema.xml within it. I presume
>> this is the collection config being used, as it is named simply
>> ‘tolkien’ as defined in the create collection command.
>
> It sounds like Solr is being started with a chroot on the zkHost
> string.  If tht's true, it means that your upconfig command is using a
> different zkHost value, and that's the problem.
>
> The zkHost string you use should be the same everywhere.  Here's an
> example of a zkHost specifying a redundant ensemble of three servers,
> and confining itself to a "/solr" chroot:
>
> server1:2181,server2:2181,server3:2181/solr
>
> The javadoc for CloudSolrClient contains some details on how zkHost
> should be constructed:
>
> http://lucene.apache.org/solr/6_3_0/solr-solrj/org/apache/solr/client/solrj/impl/CloudSolrClient.html#CloudSolrClient-java.lang.String-
>
> I personally recommend always using a chroot, but if the zookeeper
> ensemble is dedicated to a single SolrCloud cluster and no other
> software is using it, that wouldn't be necessary.
>
> Thanks,
> Shawn
>

Re: Problem managing Solr configsets on Zookeeper

Posted by Chris Rogers <ch...@bodleian.ox.ac.uk>.
Thanks Erick, Shawn, that was exactly it!



On 22/02/2017, 16:29, "Erick Erickson" <er...@gmail.com> wrote:

    This should do it:
    
    bin/solr zk upconfig -z 172.28.128.9:2181/solr -n tolkien -d
    /home/bodl-tei-svc/solr-6.4.0/server/solr/configsets/tolkien_config
    
    Or use the 'bin/solr cp -r...' command and specify the destination as
    zk:/solr/tolkien or something. upconfig/downconfig is just a  form of
    cp designed for configsets.
    
    Erick
    
    On Wed, Feb 22, 2017 at 8:27 AM, Chris Rogers
    <ch...@bodleian.ox.ac.uk> wrote:
    > Hi Shawn,
    >
    > Thanks. I am indeed using a chroot.
    >
    > In my solr.in.ih file I have the following:
    >
    > ZK_HOST="172.28.128.9/solr"
    >
    > I think I understand you’re saying that I need to specify this chroot dir in the upconfig command? Where should this be specified? Something like:
    >
    > bin/solr zk upconfig -z 172.28.128.9:2181 -n solr/configs/tolkien -d /home/bodl-tei-svc/solr-6.4.0/server/solr/configsets/tolkien_config
    >
    > Thank you for your help with this.
    >
    > Best,
    > Chris
    >
    > On 22/02/2017, 16:15, "Shawn Heisey" <ap...@elyograg.org> wrote:
    >
    >     On 2/22/2017 8:25 AM, Chris Rogers wrote:
    >     > … as uploaded with upconfig. However, in the /solr directory we have a
    >     > second /configs folder with the old schema.xml within it. I presume
    >     > this is the collection config being used, as it is named simply
    >     > ‘tolkien’ as defined in the create collection command.
    >
    >     It sounds like Solr is being started with a chroot on the zkHost
    >     string.  If tht's true, it means that your upconfig command is using a
    >     different zkHost value, and that's the problem.
    >
    >     The zkHost string you use should be the same everywhere.  Here's an
    >     example of a zkHost specifying a redundant ensemble of three servers,
    >     and confining itself to a "/solr" chroot:
    >
    >     server1:2181,server2:2181,server3:2181/solr
    >
    >     The javadoc for CloudSolrClient contains some details on how zkHost
    >     should be constructed:
    >
    >     http://lucene.apache.org/solr/6_3_0/solr-solrj/org/apache/solr/client/solrj/impl/CloudSolrClient.html#CloudSolrClient-java.lang.String-
    >
    >     I personally recommend always using a chroot, but if the zookeeper
    >     ensemble is dedicated to a single SolrCloud cluster and no other
    >     software is using it, that wouldn't be necessary.
    >
    >     Thanks,
    >     Shawn
    >
    >
    >
    


Re: Problem managing Solr configsets on Zookeeper

Posted by Erick Erickson <er...@gmail.com>.
This should do it:

bin/solr zk upconfig -z 172.28.128.9:2181/solr -n tolkien -d
/home/bodl-tei-svc/solr-6.4.0/server/solr/configsets/tolkien_config

Or use the 'bin/solr cp -r...' command and specify the destination as
zk:/solr/tolkien or something. upconfig/downconfig is just a  form of
cp designed for configsets.

Erick

On Wed, Feb 22, 2017 at 8:27 AM, Chris Rogers
<ch...@bodleian.ox.ac.uk> wrote:
> Hi Shawn,
>
> Thanks. I am indeed using a chroot.
>
> In my solr.in.ih file I have the following:
>
> ZK_HOST="172.28.128.9/solr"
>
> I think I understand you’re saying that I need to specify this chroot dir in the upconfig command? Where should this be specified? Something like:
>
> bin/solr zk upconfig -z 172.28.128.9:2181 -n solr/configs/tolkien -d /home/bodl-tei-svc/solr-6.4.0/server/solr/configsets/tolkien_config
>
> Thank you for your help with this.
>
> Best,
> Chris
>
> On 22/02/2017, 16:15, "Shawn Heisey" <ap...@elyograg.org> wrote:
>
>     On 2/22/2017 8:25 AM, Chris Rogers wrote:
>     > … as uploaded with upconfig. However, in the /solr directory we have a
>     > second /configs folder with the old schema.xml within it. I presume
>     > this is the collection config being used, as it is named simply
>     > ‘tolkien’ as defined in the create collection command.
>
>     It sounds like Solr is being started with a chroot on the zkHost
>     string.  If tht's true, it means that your upconfig command is using a
>     different zkHost value, and that's the problem.
>
>     The zkHost string you use should be the same everywhere.  Here's an
>     example of a zkHost specifying a redundant ensemble of three servers,
>     and confining itself to a "/solr" chroot:
>
>     server1:2181,server2:2181,server3:2181/solr
>
>     The javadoc for CloudSolrClient contains some details on how zkHost
>     should be constructed:
>
>     http://lucene.apache.org/solr/6_3_0/solr-solrj/org/apache/solr/client/solrj/impl/CloudSolrClient.html#CloudSolrClient-java.lang.String-
>
>     I personally recommend always using a chroot, but if the zookeeper
>     ensemble is dedicated to a single SolrCloud cluster and no other
>     software is using it, that wouldn't be necessary.
>
>     Thanks,
>     Shawn
>
>
>

Re: Problem managing Solr configsets on Zookeeper

Posted by Chris Rogers <ch...@bodleian.ox.ac.uk>.
Hi Shawn,

Thanks. I am indeed using a chroot.

In my solr.in.ih file I have the following:

ZK_HOST="172.28.128.9/solr"

I think I understand you’re saying that I need to specify this chroot dir in the upconfig command? Where should this be specified? Something like:

bin/solr zk upconfig -z 172.28.128.9:2181 -n solr/configs/tolkien -d /home/bodl-tei-svc/solr-6.4.0/server/solr/configsets/tolkien_config

Thank you for your help with this.

Best,
Chris

On 22/02/2017, 16:15, "Shawn Heisey" <ap...@elyograg.org> wrote:

    On 2/22/2017 8:25 AM, Chris Rogers wrote:
    > … as uploaded with upconfig. However, in the /solr directory we have a
    > second /configs folder with the old schema.xml within it. I presume
    > this is the collection config being used, as it is named simply
    > ‘tolkien’ as defined in the create collection command.
    
    It sounds like Solr is being started with a chroot on the zkHost
    string.  If tht's true, it means that your upconfig command is using a
    different zkHost value, and that's the problem.
    
    The zkHost string you use should be the same everywhere.  Here's an
    example of a zkHost specifying a redundant ensemble of three servers,
    and confining itself to a "/solr" chroot:
    
    server1:2181,server2:2181,server3:2181/solr
    
    The javadoc for CloudSolrClient contains some details on how zkHost
    should be constructed:
    
    http://lucene.apache.org/solr/6_3_0/solr-solrj/org/apache/solr/client/solrj/impl/CloudSolrClient.html#CloudSolrClient-java.lang.String-
    
    I personally recommend always using a chroot, but if the zookeeper
    ensemble is dedicated to a single SolrCloud cluster and no other
    software is using it, that wouldn't be necessary.
    
    Thanks,
    Shawn
    
    


Re: Problem managing Solr configsets on Zookeeper

Posted by Shawn Heisey <ap...@elyograg.org>.
On 2/22/2017 8:25 AM, Chris Rogers wrote:
> \u2026 as uploaded with upconfig. However, in the /solr directory we have a
> second /configs folder with the old schema.xml within it. I presume
> this is the collection config being used, as it is named simply
> \u2018tolkien\u2019 as defined in the create collection command.

It sounds like Solr is being started with a chroot on the zkHost
string.  If tht's true, it means that your upconfig command is using a
different zkHost value, and that's the problem.

The zkHost string you use should be the same everywhere.  Here's an
example of a zkHost specifying a redundant ensemble of three servers,
and confining itself to a "/solr" chroot:

server1:2181,server2:2181,server3:2181/solr

The javadoc for CloudSolrClient contains some details on how zkHost
should be constructed:

http://lucene.apache.org/solr/6_3_0/solr-solrj/org/apache/solr/client/solrj/impl/CloudSolrClient.html#CloudSolrClient-java.lang.String-

I personally recommend always using a chroot, but if the zookeeper
ensemble is dedicated to a single SolrCloud cluster and no other
software is using it, that wouldn't be necessary.

Thanks,
Shawn


Re: Problem managing Solr configsets on Zookeeper

Posted by Chris Rogers <ch...@bodleian.ox.ac.uk>.
Hi Erick,

Thanks for your reply.

1> Looking in the Solr UI I have only a single set of config files.
2> No, browser is not caching the page. Tried in anonymous browser and result is the same.
3> No, I don’t have a managed Schema file or managed schema factory definition. I am using <schemaFactory class="ClassicIndexSchemaFactory"/>

Further information from my investigation into the depths of Zookeeper. Using the Zookeeper cli, I have found the following znode structure:

[configs, …,  solr]

Within /configs there is the most recent and up-to-date config folder:

/configs/tolkien_config/schema.xml etc

… as uploaded with upconfig. However, in the /solr directory we have a second /configs folder with the old schema.xml within it. I presume this is the collection config being used, as it is named simply ‘tolkien’ as defined in the create collection command.

/solr/configs/tolkien/schema.xml etc

It seems that upconfig has pushed the config to zookeeper, but the config reload isn’t associating this new config.

Should the upconfig be pushing the new config directly into that /solr/configs znode?

Best,
Chris

On 22/02/2017, 15:06, "Erick Erickson" <er...@gmail.com> wrote:

    Chris:
    
    I'd check a couple of things:
    
    1> did the files get copied where you expect? Do you have only one set
    of files in the zknode configs node (admin UI>>cloud>>tree>>expand the
    appropriate branches). This seems unlikely if you did the downconfig,
    but stranger things have happened.
    
    2> Is there any chance that your _browser_ has cached the page for the
    schema file and you're seeing that?
    
    3> Chris' comment is well taken. Do you have a managed_schema file as
    well as a schema.xml file in your configset and are they different?
    You needed to change the schema factory definition in solrconfig.xml
    to _really_ use the classic schema definition. You should have
    something like this in your solrconfig.xml file:
    <schemaFactory class="ClassicIndexSchemaFactory"/>
    
    Best,
    Erick
    
    On Wed, Feb 22, 2017 at 4:54 AM, Chris Rogers
    <ch...@bodleian.ox.ac.uk> wrote:
    > Hi Gus,
    >
    > Thanks for the reply, but unfortunately this is not the problem. I am using the basic schema factory, with a directly edited schema file.
    >
    > Best,
    > Chris
    >
    > On 22/02/2017, 12:00, "Gus Heck" <gu...@gmail.com> wrote:
    >
    >     Hi Chris,
    >
    >     Are you perhaps using (by default) ManagedIndexSchemaFactory?
    >     https://cwiki.apache.org/confluence/display/solr/Schema+Factory+Definition+in+SolrConfig
    >
    >
    >     If so on first boot the schema.xml file is copied and then subsequently
    >     ignored in favor of the managed copy. If you do not wish to use the schema
    >     REST API and prefer editing a file, you can switch back to using
    >     ClassicIndexSchemaFactory (see link, bottom of page)
    >
    >     HTH,
    >     Gus
    >
    >     On Wed, Feb 22, 2017 at 6:16 AM, Chris Rogers <
    >     chris.rogers@bodleian.ox.ac.uk> wrote:
    >
    >     > Hi all,
    >     >
    >     > I’ve got a Zookeeper (3.4.8) / Solrcloud (6.4.0) setup with two nodes.
    >     >
    >     > I’ve successfully uploaded a collection through one of the Solr nodes:
    >     >
    >     > ~~~
    >     > bin/solr create -c tolkien -d  tolkien_config -s 2 -rf 2
    >     > ~~~
    >     >
    >     > I’ve then changed the schema.xml in the config set for this collection (in
    >     > the /server/solr/configsets/ folder), and used the upconfig zk command to
    >     > upload it:
    >     >
    >     > ~~~
    >     > bin/solr zk upconfig -z 172.28.128.9:2181 -n tolkien_config -d
    >     > /home/bodl-tei-svc/solr-6.4.0/server/solr/configsets/tolkien_config
    >     > ~~~
    >     >
    >     > I’ve then used the collections API to reload the collections. I’ve run
    >     > this command for both Solr nodes:
    >     >
    >     > ~~~
    >     > http://localhost:8983/solr/admin/collections?action=RELOAD&name=tolkien
    >     > ~~~
    >     >
    >     > All these commands appear to execute successfully. I can confirm that the
    >     > config is successfully uploaded to Zookeeper, as the downconfig command
    >     > returns the correct files.
    >     >
    >     > HOWEVER, the content of the Schema UI in the Solr admin does not change.
    >     > Fields I had removed were still there, and fields added were not.
    >     >
    >     > I then decided to delete the collection entirely, and recreate a new
    >     > collection with the new schema, but the schema for this new collection
    >     > remains the same as the old collection!
    >     >
    >     > It’s as if the old config has been cached somewhere or something…
    >     >
    >     > Am I missing a stage or command here?
    >     >
    >     > Many thanks,
    >     > Chris
    >     >
    >     > --
    >     > Chris Rogers
    >     > Digital Projects Manager
    >     > Bodleian Digital Library Systems and Services
    >     > chris.rogers@bodleian.ox.ac.uk
    >     >
    >
    >
    >
    >     --
    >     http://www.the111shift.com
    >
    >
    


Re: Problem managing Solr configsets on Zookeeper

Posted by Erick Erickson <er...@gmail.com>.
Chris:

I'd check a couple of things:

1> did the files get copied where you expect? Do you have only one set
of files in the zknode configs node (admin UI>>cloud>>tree>>expand the
appropriate branches). This seems unlikely if you did the downconfig,
but stranger things have happened.

2> Is there any chance that your _browser_ has cached the page for the
schema file and you're seeing that?

3> Chris' comment is well taken. Do you have a managed_schema file as
well as a schema.xml file in your configset and are they different?
You needed to change the schema factory definition in solrconfig.xml
to _really_ use the classic schema definition. You should have
something like this in your solrconfig.xml file:
<schemaFactory class="ClassicIndexSchemaFactory"/>

Best,
Erick

On Wed, Feb 22, 2017 at 4:54 AM, Chris Rogers
<ch...@bodleian.ox.ac.uk> wrote:
> Hi Gus,
>
> Thanks for the reply, but unfortunately this is not the problem. I am using the basic schema factory, with a directly edited schema file.
>
> Best,
> Chris
>
> On 22/02/2017, 12:00, "Gus Heck" <gu...@gmail.com> wrote:
>
>     Hi Chris,
>
>     Are you perhaps using (by default) ManagedIndexSchemaFactory?
>     https://cwiki.apache.org/confluence/display/solr/Schema+Factory+Definition+in+SolrConfig
>
>
>     If so on first boot the schema.xml file is copied and then subsequently
>     ignored in favor of the managed copy. If you do not wish to use the schema
>     REST API and prefer editing a file, you can switch back to using
>     ClassicIndexSchemaFactory (see link, bottom of page)
>
>     HTH,
>     Gus
>
>     On Wed, Feb 22, 2017 at 6:16 AM, Chris Rogers <
>     chris.rogers@bodleian.ox.ac.uk> wrote:
>
>     > Hi all,
>     >
>     > I’ve got a Zookeeper (3.4.8) / Solrcloud (6.4.0) setup with two nodes.
>     >
>     > I’ve successfully uploaded a collection through one of the Solr nodes:
>     >
>     > ~~~
>     > bin/solr create -c tolkien -d  tolkien_config -s 2 -rf 2
>     > ~~~
>     >
>     > I’ve then changed the schema.xml in the config set for this collection (in
>     > the /server/solr/configsets/ folder), and used the upconfig zk command to
>     > upload it:
>     >
>     > ~~~
>     > bin/solr zk upconfig -z 172.28.128.9:2181 -n tolkien_config -d
>     > /home/bodl-tei-svc/solr-6.4.0/server/solr/configsets/tolkien_config
>     > ~~~
>     >
>     > I’ve then used the collections API to reload the collections. I’ve run
>     > this command for both Solr nodes:
>     >
>     > ~~~
>     > http://localhost:8983/solr/admin/collections?action=RELOAD&name=tolkien
>     > ~~~
>     >
>     > All these commands appear to execute successfully. I can confirm that the
>     > config is successfully uploaded to Zookeeper, as the downconfig command
>     > returns the correct files.
>     >
>     > HOWEVER, the content of the Schema UI in the Solr admin does not change.
>     > Fields I had removed were still there, and fields added were not.
>     >
>     > I then decided to delete the collection entirely, and recreate a new
>     > collection with the new schema, but the schema for this new collection
>     > remains the same as the old collection!
>     >
>     > It’s as if the old config has been cached somewhere or something…
>     >
>     > Am I missing a stage or command here?
>     >
>     > Many thanks,
>     > Chris
>     >
>     > --
>     > Chris Rogers
>     > Digital Projects Manager
>     > Bodleian Digital Library Systems and Services
>     > chris.rogers@bodleian.ox.ac.uk
>     >
>
>
>
>     --
>     http://www.the111shift.com
>
>

Re: Problem managing Solr configsets on Zookeeper

Posted by Chris Rogers <ch...@bodleian.ox.ac.uk>.
Hi Gus,

Thanks for the reply, but unfortunately this is not the problem. I am using the basic schema factory, with a directly edited schema file.

Best,
Chris

On 22/02/2017, 12:00, "Gus Heck" <gu...@gmail.com> wrote:

    Hi Chris,
    
    Are you perhaps using (by default) ManagedIndexSchemaFactory?
    https://cwiki.apache.org/confluence/display/solr/Schema+Factory+Definition+in+SolrConfig
    
    
    If so on first boot the schema.xml file is copied and then subsequently
    ignored in favor of the managed copy. If you do not wish to use the schema
    REST API and prefer editing a file, you can switch back to using
    ClassicIndexSchemaFactory (see link, bottom of page)
    
    HTH,
    Gus
    
    On Wed, Feb 22, 2017 at 6:16 AM, Chris Rogers <
    chris.rogers@bodleian.ox.ac.uk> wrote:
    
    > Hi all,
    >
    > I’ve got a Zookeeper (3.4.8) / Solrcloud (6.4.0) setup with two nodes.
    >
    > I’ve successfully uploaded a collection through one of the Solr nodes:
    >
    > ~~~
    > bin/solr create -c tolkien -d  tolkien_config -s 2 -rf 2
    > ~~~
    >
    > I’ve then changed the schema.xml in the config set for this collection (in
    > the /server/solr/configsets/ folder), and used the upconfig zk command to
    > upload it:
    >
    > ~~~
    > bin/solr zk upconfig -z 172.28.128.9:2181 -n tolkien_config -d
    > /home/bodl-tei-svc/solr-6.4.0/server/solr/configsets/tolkien_config
    > ~~~
    >
    > I’ve then used the collections API to reload the collections. I’ve run
    > this command for both Solr nodes:
    >
    > ~~~
    > http://localhost:8983/solr/admin/collections?action=RELOAD&name=tolkien
    > ~~~
    >
    > All these commands appear to execute successfully. I can confirm that the
    > config is successfully uploaded to Zookeeper, as the downconfig command
    > returns the correct files.
    >
    > HOWEVER, the content of the Schema UI in the Solr admin does not change.
    > Fields I had removed were still there, and fields added were not.
    >
    > I then decided to delete the collection entirely, and recreate a new
    > collection with the new schema, but the schema for this new collection
    > remains the same as the old collection!
    >
    > It’s as if the old config has been cached somewhere or something…
    >
    > Am I missing a stage or command here?
    >
    > Many thanks,
    > Chris
    >
    > --
    > Chris Rogers
    > Digital Projects Manager
    > Bodleian Digital Library Systems and Services
    > chris.rogers@bodleian.ox.ac.uk
    >
    
    
    
    -- 
    http://www.the111shift.com
    


Re: Problem managing Solr configsets on Zookeeper

Posted by Gus Heck <gu...@gmail.com>.
Hi Chris,

Are you perhaps using (by default) ManagedIndexSchemaFactory?
https://cwiki.apache.org/confluence/display/solr/Schema+Factory+Definition+in+SolrConfig


If so on first boot the schema.xml file is copied and then subsequently
ignored in favor of the managed copy. If you do not wish to use the schema
REST API and prefer editing a file, you can switch back to using
ClassicIndexSchemaFactory (see link, bottom of page)

HTH,
Gus

On Wed, Feb 22, 2017 at 6:16 AM, Chris Rogers <
chris.rogers@bodleian.ox.ac.uk> wrote:

> Hi all,
>
> I’ve got a Zookeeper (3.4.8) / Solrcloud (6.4.0) setup with two nodes.
>
> I’ve successfully uploaded a collection through one of the Solr nodes:
>
> ~~~
> bin/solr create -c tolkien -d  tolkien_config -s 2 -rf 2
> ~~~
>
> I’ve then changed the schema.xml in the config set for this collection (in
> the /server/solr/configsets/ folder), and used the upconfig zk command to
> upload it:
>
> ~~~
> bin/solr zk upconfig -z 172.28.128.9:2181 -n tolkien_config -d
> /home/bodl-tei-svc/solr-6.4.0/server/solr/configsets/tolkien_config
> ~~~
>
> I’ve then used the collections API to reload the collections. I’ve run
> this command for both Solr nodes:
>
> ~~~
> http://localhost:8983/solr/admin/collections?action=RELOAD&name=tolkien
> ~~~
>
> All these commands appear to execute successfully. I can confirm that the
> config is successfully uploaded to Zookeeper, as the downconfig command
> returns the correct files.
>
> HOWEVER, the content of the Schema UI in the Solr admin does not change.
> Fields I had removed were still there, and fields added were not.
>
> I then decided to delete the collection entirely, and recreate a new
> collection with the new schema, but the schema for this new collection
> remains the same as the old collection!
>
> It’s as if the old config has been cached somewhere or something…
>
> Am I missing a stage or command here?
>
> Many thanks,
> Chris
>
> --
> Chris Rogers
> Digital Projects Manager
> Bodleian Digital Library Systems and Services
> chris.rogers@bodleian.ox.ac.uk
>



-- 
http://www.the111shift.com