lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damien Kamerman <dami...@gmail.com>
Subject Re: Facet Null Pointer Exception with upgraded indexes
Date Tue, 03 Jan 2017 04:21:34 GMT
Try docValues="false" in your v6 schema.xml. You will may need to upgrade
again.

On 31 December 2016 at 07:59, Mikhail Khludnev <mkhl@apache.org> wrote:

> Hi Andreu,
>
> I think it can't facet text field anymore per se
> https://issues.apache.org/jira/browse/SOLR-8362.
>
> On Fri, Dec 30, 2016 at 5:07 PM, Andreu Marimon <andreu@trovit.com> wrote:
>
> > Hi,
> >
> > I'm trying to update from solr 4.3 to 6.3. We are doing a two step
> > migration and, during the first step, we upgraded the indexes from 4.3 to
> > 5.5, which is the newest version we can get without errors using the
> Lucene
> > IndexUpgrader tool. As far as I know, 6.30 should be able to read indexes
> > generated with 5.5.
> >
> > Our problem is that, despite loading the cores and data correctly, every
> > query returns a NullPointerException during the facet counting. We can
> get
> > the results anyways, but the facets are not properly set and this error
> > appears in the response:
> >
> > "error":{
> >     "metadata":[
> >       "error-class","org.apache.solr.common.SolrException",
> >       "root-error-class","java.lang.NullPointerException"],
> >     "msg":"Exception during facet.field: fa_source",
> >     "trace":"org.apache.solr.common.SolrException: Exception during
> > facet.field: fa_source\n\tat
> > org.apache.solr.request.SimpleFacets.lambda$getFacetFieldCounts$0(
> > SimpleFacets.java:766)\n\tat
> > java.util.concurrent.FutureTask.run(FutureTask.java:266)\n\tat
> > org.apache.solr.request.SimpleFacets$2.execute(
> > SimpleFacets.java:699)\n\tat
> > org.apache.solr.request.SimpleFacets.getFacetFieldCounts(
> > SimpleFacets.java:775)\n\tat
> > org.apache.solr.handler.component.FacetComponent.
> > getFacetCounts(FacetComponent.java:321)\n\tat
> > org.apache.solr.handler.component.FacetComponent.
> > process(FacetComponent.java:265)\n\tat
> > org.apache.solr.handler.component.SearchHandler.handleRequestBody(
> > SearchHandler.java:295)\n\tat
> > org.apache.solr.handler.RequestHandlerBase.handleRequest(
> > RequestHandlerBase.java:153)\n\tat
> > org.apache.solr.core.SolrCore.execute(SolrCore.java:2213)\n\tat
> > org.apache.solr.servlet.HttpSolrCall.execute(
> HttpSolrCall.java:654)\n\tat
> > org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:460)\n\tat
> > org.apache.solr.servlet.SolrDispatchFilter.doFilter(
> > SolrDispatchFilter.java:303)\n\tat
> > org.apache.solr.servlet.SolrDispatchFilter.doFilter(
> > SolrDispatchFilter.java:254)\n\tat
> > org.eclipse.jetty.servlet.ServletHandler$CachedChain.
> > doFilter(ServletHandler.java:1668)\n\tat
> > org.eclipse.jetty.servlet.ServletHandler.doHandle(
> > ServletHandler.java:581)\n\tat
> > org.eclipse.jetty.server.handler.ScopedHandler.handle(
> > ScopedHandler.java:143)\n\tat
> > org.eclipse.jetty.security.SecurityHandler.handle(
> > SecurityHandler.java:548)\n\tat
> > org.eclipse.jetty.server.session.SessionHandler.
> > doHandle(SessionHandler.java:226)\n\tat
> > org.eclipse.jetty.server.handler.ContextHandler.
> > doHandle(ContextHandler.java:1160)\n\tat
> > org.eclipse.jetty.servlet.ServletHandler.doScope(
> > ServletHandler.java:511)\n\tat
> > org.eclipse.jetty.server.session.SessionHandler.
> > doScope(SessionHandler.java:185)\n\tat
> > org.eclipse.jetty.server.handler.ContextHandler.
> > doScope(ContextHandler.java:1092)\n\tat
> > org.eclipse.jetty.server.handler.ScopedHandler.handle(
> > ScopedHandler.java:141)\n\tat
> > org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(
> > ContextHandlerCollection.java:213)\n\tat
> > org.eclipse.jetty.server.handler.HandlerCollection.
> > handle(HandlerCollection.java:119)\n\tat
> > org.eclipse.jetty.server.handler.HandlerWrapper.handle(
> > HandlerWrapper.java:134)\n\tat
> > org.eclipse.jetty.server.Server.handle(Server.java:518)\n\tat
> > org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)\n\tat
> > org.eclipse.jetty.server.HttpConnection.onFillable(
> > HttpConnection.java:244)\n\tat
> > org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(
> > AbstractConnection.java:273)\n\tat
> > org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)\n\tat
> > org.eclipse.jetty.io.SelectChannelEndPoint$2.run(
> > SelectChannelEndPoint.java:93)\n\tat
> > org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.
> > produceAndRun(ExecuteProduceConsume.java:246)\n\tat
> > org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(
> > ExecuteProduceConsume.java:156)\n\tat
> > org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(
> > QueuedThreadPool.java:654)\n\tat
> > org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(
> > QueuedThreadPool.java:572)\n\tat
> > java.lang.Thread.run(Thread.java:745)\nCaused by:
> > java.lang.NullPointerException\n\tat
> > org.apache.solr.request.DocValuesFacets.getCounts(
> > DocValuesFacets.java:117)\n\tat
> > org.apache.solr.request.SimpleFacets.getTermCounts(
> > SimpleFacets.java:530)\n\tat
> > org.apache.solr.request.SimpleFacets.getTermCounts(
> > SimpleFacets.java:380)\n\tat
> > org.apache.solr.request.SimpleFacets.lambda$getFacetFieldCounts$0(
> > SimpleFacets.java:760)\n\t...
> > 36 more\n",
> >     "code":500}}
> >
> >
> > This facet is defined in the shcema as:
> >
> > <field name="fa_source"              type="text_facet"
> >  indexed="true"  stored="false"/>
> >
> >     <fieldType name="text_facet" class="solr.TextField"
> > positionIncrementGap="100">
> >       <analyzer>
> >         <tokenizer class="solr.KeywordTokenizerFactory"/>
> >         <filter class="solr.RemoveDuplicatesTokenFilterFactory"/>
> >       </analyzer>
> >     </fieldType>
> >
> >
> > And in the solrconfig.xml file as:
> >
> >        <str name="facet.field">fa_source</str>
> >        <str name="f.fa_source.facet.method">enum</str>
> >
> > Is there any known issue with the uprader tool that could case this
> > behaviour? Is it possible that some of this confs are not valid in solr
> 6.3
> > anymore? I could not find any similar case on the internet.
> >
> >
> > Thanks,
> > Andreu
> >
>
>
>
> --
> Sincerely yours
> Mikhail Khludnev
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message