Question regarding replica leader

Hi Solr folks, I am using solr cloud 8.4.1 . I am using* `/solr/admin/collections?action=CLUSTERSTATUS`*. Hitting this endpoint I get a list of replicas in which one is active but neither of them is leader. Something like this "core_node72": {"core": "rules_shard1_replica_n71","base_url": "node3,

Re: [CAUTION] SSL + Solr 8.5.1 in cloud mode + Java 8

Hmmm so I looked closer - it looks like a side effect of the default passthrough of the keystore being passed to the client keystore. https://github.com/apache/lucene-solr/blob/master/solr/bin/solr#L229 Can you remove or commout the entire SOLR_SSL_CLIENT_KEY_STORE section from bin/solr or bin/so

UpdateProcessorChains -cdcr processor along with ignore commit processor

Hi , Would like to have these two processors (cdcr and ignorecommit) in solrconfig.xml . But cdcr fails with below error , with either cdcr-processor-chain or ignore-commit-from-client chain version conflict for 60d35f0850afac66 expected=1671629672447737856 actual=-1,​ retry=0 commError=fals

Re: In-place update vs Atomic updates

On 7/14/2020 12:21 PM, raj.yadav wrote: As per the above statement in atomic-update, it reindex the entire document and deletes the old one. But I was going through solr documentation regarding the ( solr document update policy

Re: In-place update vs Atomic updates

Shawn Heisey-2 wrote > Atomic updates are nearly identical to simple indexing, except that the > existing document is read from the index to populate a new document > along with whatever updates were requested, then the new document is > indexed and the old one is deleted. As per the above stat

Concurrent query execution and Solr

Hi, Does anybody know if work is in progress to make Lucene's concurrent query execution accessible through Solr? I am talking about this: http://blog.mikemccandless.com/2019/10/concurrent-query-execution-in-apache.html I find this compelling in particular since the changes in LUCENE-7976 / Solr

Re: Understanding Negative Filter Queries

There’s another possibility if the person I _should_ shoot who wrote the query can’t change it; add cost=101 and turn it into a post-filter. It’s not clear to me how much difference that’d make, but it might be worth a shot, see: https://yonik.com/advanced-filter-caching-in-solr-2/ Best, Erick

Re: Solr heap Old generation grows and it is not recovered by G1GC

What kind of statistics?Are these stats that you could perhaps get from faceting or the stats component instead of gathering docs and accumulating stats yourself? > On Jul 14, 2020, at 8:51 AM, Odysci wrote: > > Hi Erick, > > I agree. The 300K docs in one search is an anomaly. > But we

Re: Solr heap Old generation grows and it is not recovered by G1GC

Hi Erick, I agree. The 300K docs in one search is an anomaly. But we do use 'fq' to return a large number of docs for the purposes of generating statistics for the whole index. We do use CursorMark extensively. Thanks! Reinaldo On Tue, Jul 14, 2020 at 8:55 AM Erick Erickson wrote: > I’d add th

Re: Understanding Negative Filter Queries

> > Well, they’ll be exactly the same if (and only if) every document has a > tag. Otherwise, the > first one will exclude a doc that has no tag and the second one will > include it. That's a good point/catch. How slow is “very slow”? > Well, in the case I was looking at it was about 10x slower

Re: Understanding Negative Filter Queries

Yeah, there are optimizations there. BTW, these two queries are subtly different. Well, they’ll be exactly the same if (and only if) every document has a tag. Otherwise, the first one will exclude a doc that has no tag and the second one will include it. How slow is “very slow”? The second for

Re: Understanding Negative Filter Queries

Hi Chris, tag:* is a wildcard query while *:* is match all query. I believe that adjusting pure negative is turned on by default so you can safely just use -tag:email and it’ll be translated to *:* -tag:email. HTH, Emir -- Monitoring - Log Management - Alerting - Anomaly Detection Solr & Elastic

Understanding Negative Filter Queries

I'm trying to understand the difference between something like fq={!cache=false}(tag:* -tag:email) which is very slow compared to fq={!cache=false}(*:* -tag:email) on Solr 7.7.1. I believe in the case of `tag:*` Solr spends some effort to gather all of the documents that have a value for `tag` and

Re: Solr heap Old generation grows and it is not recovered by G1GC

I’d add that you’re abusing Solr horribly by returning 300K documents in a single go. Solr is built to return the top N docs where N is usually quite small, < 100. If you allow an unlimited number of docs to be returned, you’re simply kicking the can down the road, somebody will ask for 1,000,00

Re: SOLR Exact phrase search issue

This is usually a result of either indexing or querying not quite doing what you expect. The screenshots don’t help diagnose as they’re just the results, but don’t really help understand why. So here’s what I do to try to figure out why: 1> add &debug=query to the query You can check the “debug