2019-07-09 17:37:30.053 INFO
(facetExecutor-67-thread-22-processing-n:127.0.0.1:8983_solr
x:products_comp-v1_shard1_replica_n21 c:products_comp-v1 s:shard1
r:core_node22) [ ] o.a.s.c.SolrCore [promotion_rules-v1_shard1_replica_n1]
**CLOSING SolrCore org.apache.solr.core.SolrCore**@44de0f89
2019
SolrQuery used:
q=*:*&defType=edismax&fl=comboid,skuid&start=0&rows=15&facet.limit=100&variant=A&debugQuery=true&debug.explain.structured=true&fq=!status_facet:inactive&fq=!mode:AF_ONLY&fq=**{!join+from=skuid+to=skuid+fromIndex=promotion_rules}id:promo-opera-test-1000_promo-opera-test-1000**&enable
Few deatils added.
public void close() {
int count = refCount.decrementAndGet();
if (count > 0) return; // close is called often, and only actually
closes if nothing is using it.
if (count < 0) {
log.error("Too many close [count:{}] on {}. Please report this
exception to solr-us
Few deatils added.
public void close() {
int count = refCount.decrementAndGet();
if (count > 0) return; // close is called often, and only actually
closes if nothing is using it.
if (count < 0) {
log.error("Too many close [count:{}] on {}. Please report this
exception to solr-us
I dint quite get your question.Our Solr collection under contention is not
shareded. Data being joint is collocated.INfact multithreaded facet help our
performance.
Afer debugging more solr 7 calls JoinQParserPlugin createWeight is called by
each thread of multithreaded facets but not in solr 6. I
In our PROD SOLR cluster(7.6 and ZK:3.4.9) when Zookeeper leader fails
Zookeeper enter an infinite leader election loop which makes SOLR instable.
Solr Fails to index(as Expected with error "Remote error message: Cannot
talk to ZooKeeper - Updates are disabled") and CPU spikes up.
This is a know
If ZK loses quorum, Solr goes read-only. That's how it's designed to
work. I don't know of any workaround for that.
That makes sense. CPU spiking in solr is because solr's index calls are
holding threads because zookeeper is down as per solr?
--
Sent from: https://lucene.472066.n3.nabble.com/
