What about SOLR-10619 and SOLR-10983? Of the two, 10619 is probably
the most important in this respect. The way the Overseer consumed
requests from the queue was very inefficient and may particularly
affect this problem. There are a couple of other JIRAs that center
around not creating unnecessary
On 10/10/2017 9:11 AM, Erick Erickson wrote:
Hmmm, that page is quite a bit out of date. I think Shawn is talking
about the "old style" Solr (4.x) that put all the state information
for all the collections in a single znode "clusterstate.json". Newer
style Solr puts each collection's state in
/co
Hmmm, that page is quite a bit out of date. I think Shawn is talking
about the "old style" Solr (4.x) that put all the state information
for all the collections in a single znode "clusterstate.json". Newer
style Solr puts each collection's state in
/collections/my_collection/state.json which has ve
In the Solr Wiki, Shawn Heisey writes the following:
"Regardless of the number of nodes or available resources, SolrCloud begins
to have stability problems when the number of collections reaches the low
hundreds. With thousands of collections, any little problem or change to
the cluster can cause
