Thanks Shawn, for the initial response.
Digging into a bit, I was wondering if we’d care to read the inner most stack.
From the inner most stack it seems to be telling us something about what
trigger it ?
Ofcourse, the system could have been overloaded as well, but is the exception
telling us something or its of no use to consider this stack
Caused by: java.lang.OutOfMemoryError: Java heap space
at
org.apache.lucene.index.FieldInfos$Builder.getOrAdd(FieldInfos.java:413)
at
org.apache.lucene.index.DefaultIndexingChain.getOrAddField(DefaultIndexingChain.java:650)
at
org.apache.lucene.index.DefaultIndexingChain.processField(DefaultIndexingChain.java:428)
at
org.apache.lucene.index.DefaultIndexingChain.processDocument(DefaultIndexingChain.java:394)
at
org.apache.lucene.index.DocumentsWriterPerThread.updateDocument(DocumentsWriterPerThread.java:251)
at
org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:494)
at
org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1609)
at
org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1601)
at
org.apache.solr.update.DirectUpdateHandler2.updateDocOrDocValues(DirectUpdateHandler2.java:964)
at
org.apache.solr.update.DirectUpdateHandler2.doNormalUpdate(DirectUpdateHandler2.java:341)
at
org.apache.solr.update.DirectUpdateHandler2.addDoc0(DirectUpdateHandler2.java:288)
at
org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:235)
at
org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:67)
at
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
at
org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalAdd(DistributedUpdateProcessor.java:970)
at
org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:1186)
at
org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:653)
at
org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:103)
at
org.apache.solr.handler.loader.JavabinLoader$1.update(JavabinLoader.java:98)
at
org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readOuterMostDocIterator(JavaBinUpdateRequestCodec.java:188)
at
org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readIterator(JavaBinUpdateRequestCodec.java:144)
at
org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:311)
at
org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:256)
at
org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readNamedList(JavaBinUpdateRequestCodec.java:130)
at
org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:276)
at
org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:256)
at
org.apache.solr.common.util.JavaBinCodec.unmarshal(JavaBinCodec.java:178)
at
org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec.unmarshal(JavaBinUpdateRequestCodec.java:195)
at
org.apache.solr.handler.loader.JavabinLoader.parseAndLoadDocs(JavabinLoader.java:109)
at
org.apache.solr.handler.loader.JavabinLoader.load(JavabinLoader.java:55)
at
org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:97)
at
org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:68)
> On Apr 1, 2019, at 4:06 PM, Shawn Heisey <apa...@elyograg.org> wrote:
>
> On 4/1/2019 4:44 PM, Aroop Ganguly wrote:
>> I am facing this issue again.The stack mentions Heap space issue.
>> Are the document sizes too big ?
>> Not sure what I should be doing here; As on the solr admin ui I do not see
>> jvm being anywhere close to being full.
>> Any advise on this is greatly welcome.
>
> <snip>
>
>> Caused by: java.lang.OutOfMemoryError: Java heap space
>
> Java ran out of heap space. This means that for what that process is being
> asked to do, its heap is too small. Solr needs more memory than it is
> allowed to use.
>
> There are exactly two things you can do.
>
> 1) Increase the heap size.
> 2) Change something so that less heap is required.
>
> The second option is not always possible.
>
> https://wiki.apache.org/solr/SolrPerformanceProblems#Java_Heap
>
> Program operation is completely unpredictable when OOME strikes. This is why
> Solr is configured to self-destruct on OutOfMemoryError when it is running on
> a non-Windows operating system. We'd like the same thing to happen for
> Windows, but don't have that capability yet.
>
> Thanks,
> Shawn
