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 Antony A <an...@gmail.com> on 2019/08/29 17:26:19 UTC
Undefined field - solr 7.2.1 cloud
Hi,
I am running on Solr cloud 7.2.1. I have 4 core collection. The fields are
available in the schema.xml in solr admin UI. This tells me zookeeper has
the correct schema. But unfortunately only the leader core has the correct
response to the query with the field while other cores are throwing the
below error stack. Restarting the core returns the correct results but
trying to avoid that situation.
o.a.s.h.RequestHandlerBase org.apache.solr.common.SolrException: undefined
field xxx
at
org.apache.solr.schema.IndexSchema.getDynamicFieldType(IndexSchema.java:1292)
at
org.apache.solr.schema.IndexSchema$SolrQueryAnalyzer.getWrappedAnalyzer(IndexSchema.java:434)
at
org.apache.lucene.analysis.DelegatingAnalyzerWrapper$DelegatingReuseStrategy.getReusableComponents(DelegatingAnalyzerWrapper.java:84)
at
org.apache.lucene.analysis.Analyzer.tokenStream(Analyzer.java:191)
at
org.apache.lucene.util.QueryBuilder.createFieldQuery(QueryBuilder.java:240)
at
org.apache.solr.parser.SolrQueryParserBase.newFieldQuery(SolrQueryParserBase.java:518)
at
org.apache.solr.parser.QueryParser.newFieldQuery(QueryParser.java:62)
at
org.apache.solr.parser.SolrQueryParserBase.getFieldQuery(SolrQueryParserBase.java:1148)
at
org.apache.solr.parser.QueryParser.MultiTerm(QueryParser.java:593)
at org.apache.solr.parser.QueryParser.Query(QueryParser.java:142)
at org.apache.solr.parser.QueryParser.Clause(QueryParser.java:282)
at org.apache.solr.parser.QueryParser.Query(QueryParser.java:162)
at org.apache.solr.parser.QueryParser.Clause(QueryParser.java:282)
at org.apache.solr.parser.QueryParser.Query(QueryParser.java:162)
at
org.apache.solr.parser.QueryParser.TopLevelQuery(QueryParser.java:131)
at
org.apache.solr.parser.SolrQueryParserBase.parse(SolrQueryParserBase.java:254)
at org.apache.solr.search.LuceneQParser.parse(LuceneQParser.java:49)
at org.apache.solr.search.QParser.getQuery(QParser.java:169)
at
org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:207)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:269)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2503)
at
org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:710)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:516)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:382)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:326)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1751)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
at
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
at
org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
at org.eclipse.jetty.server.Server.handle(Server.java:534)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)
at
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)
at
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:283)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:108)
at
org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:251)
at
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:283)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:108)
at
org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
at
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303)
at
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148)
at
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589)
at java.lang.Thread.run(Thread.java:745)
Re: Undefined field - solr 7.2.1 cloud
Posted by Erick Erickson <er...@gmail.com>.
BTW, my purpose in suggesting you remove managed schema is just to insure that you’re really using classic. Solr will blow up because it’s unable to find managed-schema if, for some strange reason, you’re really using managed.
The two can exist perfectly well together, one should be used and one ignored based on solrconfig.xml settings.
Last I knew what _can’t_ happen is you use managed schema factories and specify that your managed file is “schema.xml”, that’ll throw an error on startup. “fail early” and all that.
Best,
Erick
> On Sep 25, 2019, at 1:15 PM, Antony A <an...@gmail.com> wrote:
>
> Thanks Erick.
>
> I have removed the managed-schema for now. This setup was running perfectly
> for couple of years. I implemented basic auth around the collection a year
> back. But nothing really changed on my process to update the schema. Let me
> see if removing managed-schema has any impact and will update.
>
>
>
> On Wed, Sep 25, 2019 at 9:16 AM Erick Erickson <er...@gmail.com>
> wrote:
>
>> Then something sounds wrong with your setup. The configs are stored in ZK,
>> and read from ZooKeeper every time Solr starts. So how the replica “does
>> not have the correct schema” is a complete mystery.
>>
>> You say you have ClassicIndexSchemaFactory set up. Take a look at your
>> configs _through the Admin UI from the “collections” drop-down_ and verify.
>> This reads the same thing in ZooKeeper. Sometimes I’ve thought I was set up
>> one way and discovered later that I wasn’t.
>>
>> Next: Do you have “managed-schema” _and_ “schema.xml” in your configs? If
>> you’re indeed using classic, you can remove managed-schema.
>>
>> All to make sure your’e operating as you think you are.
>>
>> Best,
>> Erick
>>
>>> On Sep 24, 2019, at 3:58 PM, Antony A <an...@gmail.com> wrote:
>>>
>>> Hi,
>>>
>>> I also observed that whenever the JVM crashes, the replicas does not have
>>> the correct schema. Anyone seen similar behavior.
>>>
>>> Thanks,
>>> AA
>>>
>>> On Wed, Sep 4, 2019 at 9:58 PM Antony A <an...@gmail.com>
>> wrote:
>>>
>>>> Hi,
>>>>
>>>> I have confirmed that ZK ensemble is external. Even though both
>>>> managed-schema and schema.xml are on the admin ui, I see the below class
>>>> defined in solrconfig.
>>>> <schemaFactory class="ClassicIndexSchemaFactory" />
>>>>
>>>> The workaround is till to run "solr zk upconfig" followed by restarting
>>>> the cores of the collection. Anything else I should be looking into?
>>>>
>>>> Thanks
>>>>
>>>> On Wed, Sep 4, 2019 at 6:31 PM Erick Erickson <er...@gmail.com>
>>>> wrote:
>>>>
>>>>> This almost always means that you really _didn’t_ update the schema and
>>>>> reload the collection, you just thought you did ;).
>>>>>
>>>>> One common reason is to fire up Solr with an internal ZooKeeper but
>> have
>>>>> the rest of your collection be using an external ensemble.
>>>>>
>>>>> Another is to be modifying schema.xml when using managed-schema or
>>>>> vice-versa.
>>>>>
>>>>> First thing I’d do is check the ZK ensemble, are any of the ports
>>>>> reference by the admin screen anywhere 9983? If so it’s internal.
>>>>>
>>>>> Second thing I’d do is, in the admin UI, select my collection from the
>>>>> drop down list, then click files and open up the schema. Check that
>> there
>>>>> is only managed-schema or schema.xml. If both are present, check your
>>>>> solrconfig to see which one you’re using. Then open the schema and
>> check
>>>>> that your field is there. BTW, the field will be explicitly stated in
>> the
>>>>> solr log.
>>>>>
>>>>> Third thing I’d do is open the admin
>>>>> UI>>configsets>>the_configset_you’re_using and check which schema
>> you’re
>>>>> using and again if the field is in the schema.
>>>>>
>>>>> Best,
>>>>> Erick
>>>>>
>>>>>> On Sep 4, 2019, at 3:27 PM, Antony A <an...@gmail.com>
>> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I ran the collection reload after a new "leader" core was selected for
>>>>> the
>>>>>> collection due to heap failure on the previous core. But I still have
>>>>> stack
>>>>>> trace with common.SolrException: undefined field.
>>>>>>
>>>>>> On Thu, Aug 29, 2019 at 1:36 PM Antony A <an...@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>>> Yes. I do restart the cores on all the different servers. I will look
>>>>> at
>>>>>>> implementing reloading the collection. Thank you for your suggestion.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Antony
>>>>>>>
>>>>>>> On Thu, Aug 29, 2019 at 1:34 PM Shawn Heisey <ap...@elyograg.org>
>>>>> wrote:
>>>>>>>
>>>>>>>> On 8/29/2019 1:22 PM, Antony A wrote:
>>>>>>>>> I do restart Solr after changing schema using "solr zk upconfig". I
>>>>> am
>>>>>>>> yet
>>>>>>>>> to confirm but I do have a daily cron that does "delta" import.
>> Does
>>>>>>>> that
>>>>>>>>> process have any bearing on some cores losing the field?
>>>>>>>>
>>>>>>>> Did you restart all the Solr servers? If the collection lives on
>>>>>>>> multiple servers, restarting one of the servers is not going to
>> affect
>>>>>>>> replicas living on other servers.
>>>>>>>>
>>>>>>>> Reloading the collection with an HTTP request to the collections API
>>>>> is
>>>>>>>> a better option than restarting Solr.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Shawn
>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>
>>
Re: Undefined field - solr 7.2.1 cloud
Posted by Antony A <an...@gmail.com>.
Thanks Erick.
I have removed the managed-schema for now. This setup was running perfectly
for couple of years. I implemented basic auth around the collection a year
back. But nothing really changed on my process to update the schema. Let me
see if removing managed-schema has any impact and will update.
On Wed, Sep 25, 2019 at 9:16 AM Erick Erickson <er...@gmail.com>
wrote:
> Then something sounds wrong with your setup. The configs are stored in ZK,
> and read from ZooKeeper every time Solr starts. So how the replica “does
> not have the correct schema” is a complete mystery.
>
> You say you have ClassicIndexSchemaFactory set up. Take a look at your
> configs _through the Admin UI from the “collections” drop-down_ and verify.
> This reads the same thing in ZooKeeper. Sometimes I’ve thought I was set up
> one way and discovered later that I wasn’t.
>
> Next: Do you have “managed-schema” _and_ “schema.xml” in your configs? If
> you’re indeed using classic, you can remove managed-schema.
>
> All to make sure your’e operating as you think you are.
>
> Best,
> Erick
>
> > On Sep 24, 2019, at 3:58 PM, Antony A <an...@gmail.com> wrote:
> >
> > Hi,
> >
> > I also observed that whenever the JVM crashes, the replicas does not have
> > the correct schema. Anyone seen similar behavior.
> >
> > Thanks,
> > AA
> >
> > On Wed, Sep 4, 2019 at 9:58 PM Antony A <an...@gmail.com>
> wrote:
> >
> >> Hi,
> >>
> >> I have confirmed that ZK ensemble is external. Even though both
> >> managed-schema and schema.xml are on the admin ui, I see the below class
> >> defined in solrconfig.
> >> <schemaFactory class="ClassicIndexSchemaFactory" />
> >>
> >> The workaround is till to run "solr zk upconfig" followed by restarting
> >> the cores of the collection. Anything else I should be looking into?
> >>
> >> Thanks
> >>
> >> On Wed, Sep 4, 2019 at 6:31 PM Erick Erickson <er...@gmail.com>
> >> wrote:
> >>
> >>> This almost always means that you really _didn’t_ update the schema and
> >>> reload the collection, you just thought you did ;).
> >>>
> >>> One common reason is to fire up Solr with an internal ZooKeeper but
> have
> >>> the rest of your collection be using an external ensemble.
> >>>
> >>> Another is to be modifying schema.xml when using managed-schema or
> >>> vice-versa.
> >>>
> >>> First thing I’d do is check the ZK ensemble, are any of the ports
> >>> reference by the admin screen anywhere 9983? If so it’s internal.
> >>>
> >>> Second thing I’d do is, in the admin UI, select my collection from the
> >>> drop down list, then click files and open up the schema. Check that
> there
> >>> is only managed-schema or schema.xml. If both are present, check your
> >>> solrconfig to see which one you’re using. Then open the schema and
> check
> >>> that your field is there. BTW, the field will be explicitly stated in
> the
> >>> solr log.
> >>>
> >>> Third thing I’d do is open the admin
> >>> UI>>configsets>>the_configset_you’re_using and check which schema
> you’re
> >>> using and again if the field is in the schema.
> >>>
> >>> Best,
> >>> Erick
> >>>
> >>>> On Sep 4, 2019, at 3:27 PM, Antony A <an...@gmail.com>
> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> I ran the collection reload after a new "leader" core was selected for
> >>> the
> >>>> collection due to heap failure on the previous core. But I still have
> >>> stack
> >>>> trace with common.SolrException: undefined field.
> >>>>
> >>>> On Thu, Aug 29, 2019 at 1:36 PM Antony A <an...@gmail.com>
> >>> wrote:
> >>>>
> >>>>> Yes. I do restart the cores on all the different servers. I will look
> >>> at
> >>>>> implementing reloading the collection. Thank you for your suggestion.
> >>>>>
> >>>>> Cheers,
> >>>>> Antony
> >>>>>
> >>>>> On Thu, Aug 29, 2019 at 1:34 PM Shawn Heisey <ap...@elyograg.org>
> >>> wrote:
> >>>>>
> >>>>>> On 8/29/2019 1:22 PM, Antony A wrote:
> >>>>>>> I do restart Solr after changing schema using "solr zk upconfig". I
> >>> am
> >>>>>> yet
> >>>>>>> to confirm but I do have a daily cron that does "delta" import.
> Does
> >>>>>> that
> >>>>>>> process have any bearing on some cores losing the field?
> >>>>>>
> >>>>>> Did you restart all the Solr servers? If the collection lives on
> >>>>>> multiple servers, restarting one of the servers is not going to
> affect
> >>>>>> replicas living on other servers.
> >>>>>>
> >>>>>> Reloading the collection with an HTTP request to the collections API
> >>> is
> >>>>>> a better option than restarting Solr.
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Shawn
> >>>>>>
> >>>>>
> >>>
> >>>
>
>
Re: Undefined field - solr 7.2.1 cloud
Posted by Erick Erickson <er...@gmail.com>.
Then something sounds wrong with your setup. The configs are stored in ZK, and read from ZooKeeper every time Solr starts. So how the replica “does not have the correct schema” is a complete mystery.
You say you have ClassicIndexSchemaFactory set up. Take a look at your configs _through the Admin UI from the “collections” drop-down_ and verify. This reads the same thing in ZooKeeper. Sometimes I’ve thought I was set up one way and discovered later that I wasn’t.
Next: Do you have “managed-schema” _and_ “schema.xml” in your configs? If you’re indeed using classic, you can remove managed-schema.
All to make sure your’e operating as you think you are.
Best,
Erick
> On Sep 24, 2019, at 3:58 PM, Antony A <an...@gmail.com> wrote:
>
> Hi,
>
> I also observed that whenever the JVM crashes, the replicas does not have
> the correct schema. Anyone seen similar behavior.
>
> Thanks,
> AA
>
> On Wed, Sep 4, 2019 at 9:58 PM Antony A <an...@gmail.com> wrote:
>
>> Hi,
>>
>> I have confirmed that ZK ensemble is external. Even though both
>> managed-schema and schema.xml are on the admin ui, I see the below class
>> defined in solrconfig.
>> <schemaFactory class="ClassicIndexSchemaFactory" />
>>
>> The workaround is till to run "solr zk upconfig" followed by restarting
>> the cores of the collection. Anything else I should be looking into?
>>
>> Thanks
>>
>> On Wed, Sep 4, 2019 at 6:31 PM Erick Erickson <er...@gmail.com>
>> wrote:
>>
>>> This almost always means that you really _didn’t_ update the schema and
>>> reload the collection, you just thought you did ;).
>>>
>>> One common reason is to fire up Solr with an internal ZooKeeper but have
>>> the rest of your collection be using an external ensemble.
>>>
>>> Another is to be modifying schema.xml when using managed-schema or
>>> vice-versa.
>>>
>>> First thing I’d do is check the ZK ensemble, are any of the ports
>>> reference by the admin screen anywhere 9983? If so it’s internal.
>>>
>>> Second thing I’d do is, in the admin UI, select my collection from the
>>> drop down list, then click files and open up the schema. Check that there
>>> is only managed-schema or schema.xml. If both are present, check your
>>> solrconfig to see which one you’re using. Then open the schema and check
>>> that your field is there. BTW, the field will be explicitly stated in the
>>> solr log.
>>>
>>> Third thing I’d do is open the admin
>>> UI>>configsets>>the_configset_you’re_using and check which schema you’re
>>> using and again if the field is in the schema.
>>>
>>> Best,
>>> Erick
>>>
>>>> On Sep 4, 2019, at 3:27 PM, Antony A <an...@gmail.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> I ran the collection reload after a new "leader" core was selected for
>>> the
>>>> collection due to heap failure on the previous core. But I still have
>>> stack
>>>> trace with common.SolrException: undefined field.
>>>>
>>>> On Thu, Aug 29, 2019 at 1:36 PM Antony A <an...@gmail.com>
>>> wrote:
>>>>
>>>>> Yes. I do restart the cores on all the different servers. I will look
>>> at
>>>>> implementing reloading the collection. Thank you for your suggestion.
>>>>>
>>>>> Cheers,
>>>>> Antony
>>>>>
>>>>> On Thu, Aug 29, 2019 at 1:34 PM Shawn Heisey <ap...@elyograg.org>
>>> wrote:
>>>>>
>>>>>> On 8/29/2019 1:22 PM, Antony A wrote:
>>>>>>> I do restart Solr after changing schema using "solr zk upconfig". I
>>> am
>>>>>> yet
>>>>>>> to confirm but I do have a daily cron that does "delta" import. Does
>>>>>> that
>>>>>>> process have any bearing on some cores losing the field?
>>>>>>
>>>>>> Did you restart all the Solr servers? If the collection lives on
>>>>>> multiple servers, restarting one of the servers is not going to affect
>>>>>> replicas living on other servers.
>>>>>>
>>>>>> Reloading the collection with an HTTP request to the collections API
>>> is
>>>>>> a better option than restarting Solr.
>>>>>>
>>>>>> Thanks,
>>>>>> Shawn
>>>>>>
>>>>>
>>>
>>>
Re: Undefined field - solr 7.2.1 cloud
Posted by Antony A <an...@gmail.com>.
Hi,
I also observed that whenever the JVM crashes, the replicas does not have
the correct schema. Anyone seen similar behavior.
Thanks,
AA
On Wed, Sep 4, 2019 at 9:58 PM Antony A <an...@gmail.com> wrote:
> Hi,
>
> I have confirmed that ZK ensemble is external. Even though both
> managed-schema and schema.xml are on the admin ui, I see the below class
> defined in solrconfig.
> <schemaFactory class="ClassicIndexSchemaFactory" />
>
> The workaround is till to run "solr zk upconfig" followed by restarting
> the cores of the collection. Anything else I should be looking into?
>
> Thanks
>
> On Wed, Sep 4, 2019 at 6:31 PM Erick Erickson <er...@gmail.com>
> wrote:
>
>> This almost always means that you really _didn’t_ update the schema and
>> reload the collection, you just thought you did ;).
>>
>> One common reason is to fire up Solr with an internal ZooKeeper but have
>> the rest of your collection be using an external ensemble.
>>
>> Another is to be modifying schema.xml when using managed-schema or
>> vice-versa.
>>
>> First thing I’d do is check the ZK ensemble, are any of the ports
>> reference by the admin screen anywhere 9983? If so it’s internal.
>>
>> Second thing I’d do is, in the admin UI, select my collection from the
>> drop down list, then click files and open up the schema. Check that there
>> is only managed-schema or schema.xml. If both are present, check your
>> solrconfig to see which one you’re using. Then open the schema and check
>> that your field is there. BTW, the field will be explicitly stated in the
>> solr log.
>>
>> Third thing I’d do is open the admin
>> UI>>configsets>>the_configset_you’re_using and check which schema you’re
>> using and again if the field is in the schema.
>>
>> Best,
>> Erick
>>
>> > On Sep 4, 2019, at 3:27 PM, Antony A <an...@gmail.com> wrote:
>> >
>> > Hi,
>> >
>> > I ran the collection reload after a new "leader" core was selected for
>> the
>> > collection due to heap failure on the previous core. But I still have
>> stack
>> > trace with common.SolrException: undefined field.
>> >
>> > On Thu, Aug 29, 2019 at 1:36 PM Antony A <an...@gmail.com>
>> wrote:
>> >
>> >> Yes. I do restart the cores on all the different servers. I will look
>> at
>> >> implementing reloading the collection. Thank you for your suggestion.
>> >>
>> >> Cheers,
>> >> Antony
>> >>
>> >> On Thu, Aug 29, 2019 at 1:34 PM Shawn Heisey <ap...@elyograg.org>
>> wrote:
>> >>
>> >>> On 8/29/2019 1:22 PM, Antony A wrote:
>> >>>> I do restart Solr after changing schema using "solr zk upconfig". I
>> am
>> >>> yet
>> >>>> to confirm but I do have a daily cron that does "delta" import. Does
>> >>> that
>> >>>> process have any bearing on some cores losing the field?
>> >>>
>> >>> Did you restart all the Solr servers? If the collection lives on
>> >>> multiple servers, restarting one of the servers is not going to affect
>> >>> replicas living on other servers.
>> >>>
>> >>> Reloading the collection with an HTTP request to the collections API
>> is
>> >>> a better option than restarting Solr.
>> >>>
>> >>> Thanks,
>> >>> Shawn
>> >>>
>> >>
>>
>>
Re: Undefined field - solr 7.2.1 cloud
Posted by Antony A <an...@gmail.com>.
Hi,
I have confirmed that ZK ensemble is external. Even though both
managed-schema and schema.xml are on the admin ui, I see the below class
defined in solrconfig.
<schemaFactory class="ClassicIndexSchemaFactory" />
The workaround is till to run "solr zk upconfig" followed by restarting the
cores of the collection. Anything else I should be looking into?
Thanks
On Wed, Sep 4, 2019 at 6:31 PM Erick Erickson <er...@gmail.com>
wrote:
> This almost always means that you really _didn’t_ update the schema and
> reload the collection, you just thought you did ;).
>
> One common reason is to fire up Solr with an internal ZooKeeper but have
> the rest of your collection be using an external ensemble.
>
> Another is to be modifying schema.xml when using managed-schema or
> vice-versa.
>
> First thing I’d do is check the ZK ensemble, are any of the ports
> reference by the admin screen anywhere 9983? If so it’s internal.
>
> Second thing I’d do is, in the admin UI, select my collection from the
> drop down list, then click files and open up the schema. Check that there
> is only managed-schema or schema.xml. If both are present, check your
> solrconfig to see which one you’re using. Then open the schema and check
> that your field is there. BTW, the field will be explicitly stated in the
> solr log.
>
> Third thing I’d do is open the admin
> UI>>configsets>>the_configset_you’re_using and check which schema you’re
> using and again if the field is in the schema.
>
> Best,
> Erick
>
> > On Sep 4, 2019, at 3:27 PM, Antony A <an...@gmail.com> wrote:
> >
> > Hi,
> >
> > I ran the collection reload after a new "leader" core was selected for
> the
> > collection due to heap failure on the previous core. But I still have
> stack
> > trace with common.SolrException: undefined field.
> >
> > On Thu, Aug 29, 2019 at 1:36 PM Antony A <an...@gmail.com>
> wrote:
> >
> >> Yes. I do restart the cores on all the different servers. I will look at
> >> implementing reloading the collection. Thank you for your suggestion.
> >>
> >> Cheers,
> >> Antony
> >>
> >> On Thu, Aug 29, 2019 at 1:34 PM Shawn Heisey <ap...@elyograg.org>
> wrote:
> >>
> >>> On 8/29/2019 1:22 PM, Antony A wrote:
> >>>> I do restart Solr after changing schema using "solr zk upconfig". I am
> >>> yet
> >>>> to confirm but I do have a daily cron that does "delta" import. Does
> >>> that
> >>>> process have any bearing on some cores losing the field?
> >>>
> >>> Did you restart all the Solr servers? If the collection lives on
> >>> multiple servers, restarting one of the servers is not going to affect
> >>> replicas living on other servers.
> >>>
> >>> Reloading the collection with an HTTP request to the collections API is
> >>> a better option than restarting Solr.
> >>>
> >>> Thanks,
> >>> Shawn
> >>>
> >>
>
>
Re: Undefined field - solr 7.2.1 cloud
Posted by Erick Erickson <er...@gmail.com>.
This almost always means that you really _didn’t_ update the schema and reload the collection, you just thought you did ;).
One common reason is to fire up Solr with an internal ZooKeeper but have the rest of your collection be using an external ensemble.
Another is to be modifying schema.xml when using managed-schema or vice-versa.
First thing I’d do is check the ZK ensemble, are any of the ports reference by the admin screen anywhere 9983? If so it’s internal.
Second thing I’d do is, in the admin UI, select my collection from the drop down list, then click files and open up the schema. Check that there is only managed-schema or schema.xml. If both are present, check your solrconfig to see which one you’re using. Then open the schema and check that your field is there. BTW, the field will be explicitly stated in the solr log.
Third thing I’d do is open the admin UI>>configsets>>the_configset_you’re_using and check which schema you’re using and again if the field is in the schema.
Best,
Erick
> On Sep 4, 2019, at 3:27 PM, Antony A <an...@gmail.com> wrote:
>
> Hi,
>
> I ran the collection reload after a new "leader" core was selected for the
> collection due to heap failure on the previous core. But I still have stack
> trace with common.SolrException: undefined field.
>
> On Thu, Aug 29, 2019 at 1:36 PM Antony A <an...@gmail.com> wrote:
>
>> Yes. I do restart the cores on all the different servers. I will look at
>> implementing reloading the collection. Thank you for your suggestion.
>>
>> Cheers,
>> Antony
>>
>> On Thu, Aug 29, 2019 at 1:34 PM Shawn Heisey <ap...@elyograg.org> wrote:
>>
>>> On 8/29/2019 1:22 PM, Antony A wrote:
>>>> I do restart Solr after changing schema using "solr zk upconfig". I am
>>> yet
>>>> to confirm but I do have a daily cron that does "delta" import. Does
>>> that
>>>> process have any bearing on some cores losing the field?
>>>
>>> Did you restart all the Solr servers? If the collection lives on
>>> multiple servers, restarting one of the servers is not going to affect
>>> replicas living on other servers.
>>>
>>> Reloading the collection with an HTTP request to the collections API is
>>> a better option than restarting Solr.
>>>
>>> Thanks,
>>> Shawn
>>>
>>
Re: Undefined field - solr 7.2.1 cloud
Posted by Antony A <an...@gmail.com>.
Hi,
I ran the collection reload after a new "leader" core was selected for the
collection due to heap failure on the previous core. But I still have stack
trace with common.SolrException: undefined field.
On Thu, Aug 29, 2019 at 1:36 PM Antony A <an...@gmail.com> wrote:
> Yes. I do restart the cores on all the different servers. I will look at
> implementing reloading the collection. Thank you for your suggestion.
>
> Cheers,
> Antony
>
> On Thu, Aug 29, 2019 at 1:34 PM Shawn Heisey <ap...@elyograg.org> wrote:
>
>> On 8/29/2019 1:22 PM, Antony A wrote:
>> > I do restart Solr after changing schema using "solr zk upconfig". I am
>> yet
>> > to confirm but I do have a daily cron that does "delta" import. Does
>> that
>> > process have any bearing on some cores losing the field?
>>
>> Did you restart all the Solr servers? If the collection lives on
>> multiple servers, restarting one of the servers is not going to affect
>> replicas living on other servers.
>>
>> Reloading the collection with an HTTP request to the collections API is
>> a better option than restarting Solr.
>>
>> Thanks,
>> Shawn
>>
>
Re: Undefined field - solr 7.2.1 cloud
Posted by Antony A <an...@gmail.com>.
Yes. I do restart the cores on all the different servers. I will look at
implementing reloading the collection. Thank you for your suggestion.
Cheers,
Antony
On Thu, Aug 29, 2019 at 1:34 PM Shawn Heisey <ap...@elyograg.org> wrote:
> On 8/29/2019 1:22 PM, Antony A wrote:
> > I do restart Solr after changing schema using "solr zk upconfig". I am
> yet
> > to confirm but I do have a daily cron that does "delta" import. Does that
> > process have any bearing on some cores losing the field?
>
> Did you restart all the Solr servers? If the collection lives on
> multiple servers, restarting one of the servers is not going to affect
> replicas living on other servers.
>
> Reloading the collection with an HTTP request to the collections API is
> a better option than restarting Solr.
>
> Thanks,
> Shawn
>
Re: Undefined field - solr 7.2.1 cloud
Posted by Shawn Heisey <ap...@elyograg.org>.
On 8/29/2019 1:22 PM, Antony A wrote:
> I do restart Solr after changing schema using "solr zk upconfig". I am yet
> to confirm but I do have a daily cron that does "delta" import. Does that
> process have any bearing on some cores losing the field?
Did you restart all the Solr servers? If the collection lives on
multiple servers, restarting one of the servers is not going to affect
replicas living on other servers.
Reloading the collection with an HTTP request to the collections API is
a better option than restarting Solr.
Thanks,
Shawn
Re: Undefined field - solr 7.2.1 cloud
Posted by Antony A <an...@gmail.com>.
I do restart Solr after changing schema using "solr zk upconfig". I am yet
to confirm but I do have a daily cron that does "delta" import. Does that
process have any bearing on some cores losing the field?
On Thu, Aug 29, 2019 at 11:32 AM Shawn Heisey <ap...@elyograg.org> wrote:
> On 8/29/2019 11:26 AM, Antony A wrote:
> > Hi,
> >
> > I am running on Solr cloud 7.2.1. I have 4 core collection. The fields
> are
> > available in the schema.xml in solr admin UI. This tells me zookeeper has
> > the correct schema. But unfortunately only the leader core has the
> correct
> > response to the query with the field while other cores are throwing the
> > below error stack. Restarting the core returns the correct results but
> > trying to avoid that situation.
> >
> > o.a.s.h.RequestHandlerBase org.apache.solr.common.SolrException:
> undefined
> > field xxx
>
> This sounds like the schema got updated to add the referenced field, but
> some or all of the cores were never reloaded. So when you do the core
> reload (or restart Solr), it's good on that core, but not on a core that
> didn't get reloaded.
>
> Whenever you make changes to the config files in ZooKeeper, you should
> reload the collection. This will reload all the individual cores on
> whatever servers they happen to reside on, which will cause them to
> re-read the config files.
>
> https://lucene.apache.org/solr/guide/7_2/collections-api.html#reload
>
> Thanks,
> Shawn
>
Re: Undefined field - solr 7.2.1 cloud
Posted by Shawn Heisey <ap...@elyograg.org>.
On 8/29/2019 11:26 AM, Antony A wrote:
> Hi,
>
> I am running on Solr cloud 7.2.1. I have 4 core collection. The fields are
> available in the schema.xml in solr admin UI. This tells me zookeeper has
> the correct schema. But unfortunately only the leader core has the correct
> response to the query with the field while other cores are throwing the
> below error stack. Restarting the core returns the correct results but
> trying to avoid that situation.
>
> o.a.s.h.RequestHandlerBase org.apache.solr.common.SolrException: undefined
> field xxx
This sounds like the schema got updated to add the referenced field, but
some or all of the cores were never reloaded. So when you do the core
reload (or restart Solr), it's good on that core, but not on a core that
didn't get reloaded.
Whenever you make changes to the config files in ZooKeeper, you should
reload the collection. This will reload all the individual cores on
whatever servers they happen to reside on, which will cause them to
re-read the config files.
https://lucene.apache.org/solr/guide/7_2/collections-api.html#reload
Thanks,
Shawn