A pod restart could be the issue as each Solr pod is showing 1 restart. But
the logs are so clean that it didn't capture any sign of a restart if it
happened within the one minute window between the initial start and failed
collection creation.
Joel Bernstein
http://joelsolr.blogspot.com/
On M
RE ZK multi: https://issues.apache.org/jira/browse/SOLR-14446
Also recently on main, a configSet was made to be considered nonexistent
until solrconfig.xml shows up -- SOLR-15421
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Mon, Jun 21, 2021 at 6
To be clear, I meant did the Solr pod get killed while it was creating
the _default configset? (Not when creating your test collection, the
problem already existed once you got to that point, obviously)
On Mon, Jun 21, 2021 at 4:01 PM Timothy Potter wrote:
>
> I've not seen this happen ... did yo
I've not seen this happen ... did your Solr pod get killed during this
operation? I'm not sure if this copy operation could be done as a
multi given the jute buffer limitations (iirc, the total size of all
setData for a multi must be under the jute buffer size) ... so it's
possible to end up with a
I was deploying the solr-operator in GKE and everything worked as expected
except for one error and I was wondering if others had come across this. I
was using the same commands and example deployment described here:
https://solr.apache.org/operator/articles/explore-v030-gke.html.
The _default con
