Hello Solr Expert,
   We are using Solr 6.3.0 and lately we are unable to write documents into our 
index. Please see below error messages. Can anyone help us?
   Thank you.


===================================================================================================================
org.apache.solr.common.SolrException: Exception writing document id 
3b8514819e204cc7a110aa5752e29b8e to the index; possible analysis error.
        at 
org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:178)
        at 
org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:67)
        at 
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:48)
        at 
org.apache.solr.update.processor.AddSchemaFieldsUpdateProcessorFactory$AddSchemaFieldsUpdateProcessor.processAdd(AddSchemaFieldsUpdateProcessorFactory.java:335)
        at 
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:48)
        at 
org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)
        at 
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:48)
        at 
org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)
        at 
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:48)
        at 
org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)
        at 
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:48)
        at 
org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)
        at 
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:48)
        at 
org.apache.solr.update.processor.FieldNameMutatingUpdateProcessorFactory$1.processAdd(FieldNameMutatingUpdateProcessorFactory.java:74)
        at 
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:48)
        at 
org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)
        at 
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:48)
        at 
org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalAdd(DistributedUpdateProcessor.java:957)
        at 
org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:1112)
        at 
org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:738)
        at 
org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:103)
        at 
org.apache.solr.handler.loader.JavabinLoader$1.update(JavabinLoader.java:97)
        at 
org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readOuterMostDocIterator(JavaBinUpdateRequestCodec.java:179)
        at 
org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readIterator(JavaBinUpdateRequestCodec.java:135)
        at 
org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:275)
        at 
org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readNamedList(JavaBinUpdateRequestCodec.java:121)
        at 
org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:240)
        at 
org.apache.solr.common.util.JavaBinCodec.unmarshal(JavaBinCodec.java:158)
        at 
org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec.unmarshal(JavaBinUpdateRequestCodec.java:186)
        at 
org.apache.solr.handler.loader.JavabinLoader.parseAndLoadDocs(JavabinLoader.java:107)
        at 
org.apache.solr.handler.loader.JavabinLoader.load(JavabinLoader.java:54)
        at 
org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:97)
        at 
org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:68)
        at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:153)
        at org.apache.solr.core.SolrCore.execute(SolrCore.java:2213)
        at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:654)
        at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:460)
        at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:303)
        at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:254)
        at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)
        at 
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)
        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:1160)
        at 
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)
        at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
        at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)
        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.server.Server.handle(Server.java:518)
        at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)
        at 
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244)
        at 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
        at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
        at 
org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
        at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceAndRun(ExecuteProduceConsume.java:246)
        at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:156)
        at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:654)
        at 
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:572)
        at java.lang.Thread.run(Thread.java:745)
Caused by: org.apache.lucene.store.AlreadyClosedException: this IndexWriter is 
closed
        at org.apache.lucene.index.IndexWriter.ensureOpen(IndexWriter.java:740)
        at org.apache.lucene.index.IndexWriter.ensureOpen(IndexWriter.java:754)
        at 
org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1558)
        at 
org.apache.solr.update.DirectUpdateHandler2.doNormalUpdate(DirectUpdateHandler2.java:279)
        at 
org.apache.solr.update.DirectUpdateHandler2.addDoc0(DirectUpdateHandler2.java:211)
        at 
org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:166)
        ... 62 more
Caused by: java.lang.ArrayIndexOutOfBoundsException
        at 
org.apache.lucene.store.BufferedIndexInput.readBytes(BufferedIndexInput.java:125)
        at 
org.apache.lucene.store.BufferedIndexInput.readBytes(BufferedIndexInput.java:116)
        at 
org.apache.lucene.codecs.lucene54.Lucene54DocValuesProducer$CompressedBinaryDocValues$CompressedBinaryTermsEnum.readTerm(Lucene54DocValuesProducer.java:1349)
        at 
org.apache.lucene.codecs.lucene54.Lucene54DocValuesProducer$CompressedBinaryDocValues$CompressedBinaryTermsEnum.next(Lucene54DocValuesProducer.java:1365)
        at 
org.apache.lucene.index.MultiTermsEnum.pushTop(MultiTermsEnum.java:275)
        at org.apache.lucene.index.MultiTermsEnum.next(MultiTermsEnum.java:301)
        at 
org.apache.lucene.index.MultiDocValues$OrdinalMap.<init>(MultiDocValues.java:527)
        at 
org.apache.lucene.index.MultiDocValues$OrdinalMap.build(MultiDocValues.java:484)
        at 
org.apache.lucene.codecs.DocValuesConsumer.mergeSortedField(DocValuesConsumer.java:638)
        at 
org.apache.lucene.codecs.DocValuesConsumer.merge(DocValuesConsumer.java:204)
        at 
org.apache.lucene.codecs.perfield.PerFieldDocValuesFormat$FieldsWriter.merge(PerFieldDocValuesFormat.java:153)
        at 
org.apache.lucene.index.SegmentMerger.mergeDocValues(SegmentMerger.java:167)
        at org.apache.lucene.index.SegmentMerger.merge(SegmentMerger.java:111)
        at 
org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:4312)
        at org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:3889)
        at 
org.apache.lucene.index.ConcurrentMergeScheduler.doMerge(ConcurrentMergeScheduler.java:588)
        at 
org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:626)



Kind regards,

Daphne Liu
BI Architect • Big Data - Matrix SCM

CEVA Logistics / 10751 Deerwood Park Blvd, Suite 200, Jacksonville, FL 32256 
USA / www.cevalogistics.com
T 904.9281448 / F 904.928.1525 / daphne....@cevalogistics.com

Making business flow


-----Original Message-----
From: Erick Erickson <erickerick...@gmail.com>
Sent: Wednesday, July 11, 2018 4:51 PM
To: solr-user <solr-user@lucene.apache.org>
Subject: Re: solr filter query on text field

bq.  is there any difference if the fq field is a string field vs test

Absolutely. string fields are not analyzed in any way. They're not tokenized. 
There are case sensitive. Etc. For example takd My dog as input. A string field 
will have a _single_ token "My dog.". It will not match a search on "my". It 
will not match a search on "dog". It won't even match "my dog." as a phrase 
since the case is different. It won't even match "My dog" because there's no 
period at the end. It will only match "My dog.".

As a text field, there would be two tokens, "My" and "dog", and they'd be 
massaged however your filters arrange things. With the usual filters in place 
(lowerCaseFilter in particular) the tokens in the index would be "my" and "dog" 
so searches on "my" would match, "My"
would match, "dog" OR "my" would match

Best,
Erick

On Wed, Jul 11, 2018 at 12:01 PM, Wei <weiwan...@gmail.com> wrote:
> btw, is there any difference if the fq field is a string field vs test
> field?
>
> On Wed, Jul 11, 2018 at 11:59 AM, Wei <weiwan...@gmail.com> wrote:
>
>> Thanks Erick and Andrea!  If my default operator is OR,  fq=
>> my_text_field:(Jurassic park the movie)  is equivalent to
>> my_text_field:(Jurassic OR park OR the OR movie)? That make sense.
>>
>> On Wed, Jul 11, 2018 at 9:06 AM, Andrea Gazzarini
>> <a.gazzar...@sease.io>
>> wrote:
>>
>>> The syntax is valid in all those three examples, the right one
>>> depends on what you need.
>>>
>>> The first query executes a proximity search (you can think to a
>>> phrase search, for simplicity) so it returns no result because
>>> probably you don't have any matching docs with that whole literal.
>>>
>>> The second is querying the my_text_field for all terms which compose
>>> the value between parenthesis. You can think to a query where each
>>> term is an optional clause, something like mytextfield:jurassic OR
>>> mytextfiekd:park...
>>> (it's not exactly an OR but this could give you the idea=
>>>
>>> The third example is not doing what you think. My_text_field is used
>>> only with the first term (Jurassic) while the others are using the
>>> default field. Something like mytextfield:jurassic OR
>>> defaultfield:park OR defaultfield:the.... That's the reason  you
>>> have so many results (I guess the default field is a catch-all
>>> field)
>>>
>>> Sorry for typos I'm using my mobile
>>>
>>> Andrea
>>>
>>> Il mer 11 lug 2018, 17:54 Wei <weiwan...@gmail.com> ha scritto:
>>>
>>> > Hi,
>>> >
>>> > I am running filter query on a field of text_general type and see
>>> > completely different results for the following queries:
>>> >
>>> >    fq= my_text_field:"Jurassic park the movie"               returns 0
>>> > result
>>> >
>>> >    fq= my_text_field:(Jurassic park the movie)               returns 20
>>> > result
>>> >
>>> >    fq= my_text_field:Jurassic park the movie                  returns
>>> > thousands of results
>>> >
>>> >
>>> > Which one is the correct syntax? I am confused why the first query
>>> doesn't
>>> > have any match at all.  I also thought 2 and 3 are the same, but
>>> > turns
>>> out
>>> > quite different.
>>> >
>>> >
>>> > Thanks,
>>> > Wei
>>> >
>>>
>>
>>

NVOCC Services are provided by CEVA as agents for and on behalf of Pyramid 
Lines Limited trading as Pyramid Lines.
This e-mail message is intended for the above named recipient(s) only. It may 
contain confidential information that is privileged. If you are not the 
intended recipient, you are hereby notified that any dissemination, 
distribution or copying of this e-mail and any attachment(s) is strictly 
prohibited. If you have received this e-mail by error, please immediately 
notify the sender by replying to this e-mail and deleting the message including 
any attachment(s) from your system. Thank you in advance for your cooperation 
and assistance. Although the company has taken reasonable precautions to ensure 
no viruses are present in this email, the company cannot accept responsibility 
for any loss or damage arising from the use of this email or attachments.

Reply via email to