lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aroop Ganguly <>
Subject Re: Solr 7.5 - Indexing Failing due to "IndexWriter is Closed"
Date Mon, 01 Apr 2019 23:40:09 GMT
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(
	at org.apache.lucene.index.DefaultIndexingChain.getOrAddField(
	at org.apache.lucene.index.DefaultIndexingChain.processField(
	at org.apache.lucene.index.DefaultIndexingChain.processDocument(
	at org.apache.lucene.index.DocumentsWriterPerThread.updateDocument(
	at org.apache.lucene.index.DocumentsWriter.updateDocument(
	at org.apache.lucene.index.IndexWriter.updateDocument(
	at org.apache.lucene.index.IndexWriter.updateDocument(
	at org.apache.solr.update.DirectUpdateHandler2.updateDocOrDocValues(
	at org.apache.solr.update.DirectUpdateHandler2.doNormalUpdate(
	at org.apache.solr.update.DirectUpdateHandler2.addDoc0(
	at org.apache.solr.update.DirectUpdateHandler2.addDoc(
	at org.apache.solr.update.processor.RunUpdateProcessor.processAdd(
	at org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(
	at org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalAdd(
	at org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(
	at org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(
	at org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.processAdd(
	at org.apache.solr.handler.loader.JavabinLoader$1.update(
	at org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readOuterMostDocIterator(
	at org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readIterator(
	at org.apache.solr.common.util.JavaBinCodec.readObject(
	at org.apache.solr.common.util.JavaBinCodec.readVal(
	at org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readNamedList(
	at org.apache.solr.common.util.JavaBinCodec.readObject(
	at org.apache.solr.common.util.JavaBinCodec.readVal(
	at org.apache.solr.common.util.JavaBinCodec.unmarshal(
	at org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec.unmarshal(
	at org.apache.solr.handler.loader.JavabinLoader.parseAndLoadDocs(
	at org.apache.solr.handler.loader.JavabinLoader.load(
	at org.apache.solr.handler.UpdateRequestHandler$1.load(
	at org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(

> On Apr 1, 2019, at 4:06 PM, Shawn Heisey <> 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.
> 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

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