lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shawn Heisey <apa...@elyograg.org>
Subject Re: Docker and Solr Indexing
Date Wed, 12 Sep 2018 03:42:13 GMT
On 9/11/2018 9:20 PM, solrnoobie wrote:
> So what we did is we upgraded the instances to 16 gigs and we rarely
> encounter this now.
>
> So what we did was to increase the batch size to 500 instead of 50 and it
> worked for our test data. But when we tried 1000 batch size, the invalid
> content type error returned. Can you guys shed some light on why this is
> happening? I don't think that a thousand per batch is too much (although we
> have documents with many fields and child documents) so I am not really sure
> what's causing this aside from a docker containter restart.

At no point in this thread have you shared the actual error messages.  
Without those and the exact version of Solr, it's difficult to help 
you.  Saying that you got a "content type error" doesn't mean anything.  
We need to see the actual error, complete with all stacktrace data.  The 
best information will be found in the logfile -- solr.log.

Solr (as packaged by this project) is not designed to restart itself 
automatically.  If the JVM encounters an OutOfMemoryError exception and 
the platform is NOT Windows, then Solr is designed to kill itself ... 
but it will NOT automatically restart without outside intervention or a 
change to its startup scripts.  This is done because program operation 
is completely unpredictable when OOME hits, so the best course of action 
is to self-terminate and let the admin fix the problem that cause the OOME.

The publicly available Solr docker container is NOT an official product 
of this project.  It is third-party, so problems specific to the docker 
container may need to be handled by the project that created it.  If the 
docker container is set up to automatically restart Solr when it dies, I 
would consider that to be a bug. About the only reason that Solr will 
ever die is the OOME self-termination that I already described ... and 
since the OOME is likely to occur again after restart, it's usually 
better for the software to stay offline until the admin fixes the problem.

Thanks,
Shawn


Mime
View raw message