Re: Commits (with openSearcher = true) are too slow in solr 8

On 11/3/2020 11:46 PM, raj.yadav wrote: We have two parallel system one is solr 8.5.2 and other one is solr 5.4 In solr_5.4 commit time with opensearcher true is 10 to 12 minutes while in solr_8 it's around 25 minutes. Commits on a properly configured and sized system should take a few

Re: Solr migration related issues.

Thanks Erick and Ilan. I am using APIs to create core and collection and have removed all the entries from core.properties. Currently I am facing init failure and debugging it. Will write back if I am facing any issues. Best, Modassar On Wed, Nov 4, 2020 at 3:20 AM Erick Erickson wrote: > Do

Commits (with openSearcher = true) are too slow in solr 8

Hi everyone, We have two parallel system one is solr 8.5.2 and other one is solr 5.4 In solr_5.4 commit time with opensearcher true is 10 to 12 minutes while in solr_8 it's around 25 minutes. This is our current caching policy of solr_8 In solr 5, we are using FastLRUCache

docValues usage

Hi, I have a couple of primitive single value numeric type fields, their values are used in boosting functions, but not used in sort/facet. or in returned response. Should I use docValues for them in the schema? I can think of the following options: 1) indexed=true, stored=true,

Re: download binary files will not uncompress

Routing back to the mailing list, please do not reply directly to individual emails. You did not download the complete file, the releases should be approximately 180MB, not the 30KB that you show. Try downloading from a different mirror, or check if you are behind a proxy or firewall preventing

Re: download binary files will not uncompress

Can you check the signatures to make sure your downloads were not corrupted? I just checked and was able to download and uncompress both of them. Also, depending on your version of tar, you don't want the - for your flags... tar xf solr-8.6.3.tgz Mike On Tue, Nov 3, 2020 at 4:15 PM James Rome

download binary files will not uncompress

# Source release: solr-8.6.3-src.tgz [PGP ] [SHA512 ] # Binary

Re: Solr migration related issues.

Do note, though, that the default value for legacyCloud changed from true to false so even though you can get it to work by setting this cluster prop I wouldn’t… The change in the default value is why it’s failing for you. > On Nov 3, 2020, at 11:20 AM, Ilan Ginzburg wrote: > > I second

Re: Solr tag cloud - words and counts

For a tag cloud, the anomalous words are what you want. If you choose the most common words, then every tag cloud will have the same words. It will look like: the, be, to, it, of, and, a, in, that, have, I, it, for, not, on, with, ... wunder Walter Underwood wun...@wunderwood.org

Solr tag cloud - words and counts

I have been trying to find a way to do this in Solr for a while. Perform a query, and for a text_general field in the result set, find each term's # of occurences. - I tried the Terms Component, it doesn't have the ability to restrict the result set with a query. - Tried faceting on the

solr-exporter using string arrays - 2

Sorry for the bad format of the first mail, once again: Hello there, while playing around with the https://github.com/apache/lucene-solr/blob/master/solr/contrib/prometheus-exporter/conf/solr-exporter-config.xml I found a bug when trying to use string arrays like 'facet.field':

~solr-exporter using string arrays

Hello there, while playing around with the https://github.com/apache/lucene-solr/blob/master/solr/contrib/prometheus-exporter/conf/solr-exporter-config.xml I found a bug when trying to use string arrays like 'facet.field': __ __ __ __ __ __ _test_ _/select_ __ __ __

Re: how do you manage your config and schema

Is there a more conservative starting point that is still up to date than _default? On Tue, Nov 3, 2020 at 11:13 AM matthew sporleder wrote: > > So _default considered unsafe? :) > > On Tue, Nov 3, 2020 at 11:08 AM Erick Erickson > wrote: > > > > The caution I would add is that you should be

Re: Solr migration related issues.

I second Erick's recommendation, but just for the record legacyCloud was removed in (upcoming) Solr 9 and is still available in Solr 8.x. Most likely this explains Modassar why you found it in the documentation. Ilan On Tue, Nov 3, 2020 at 5:11 PM Erick Erickson wrote: > You absolutely need

Re: how do you manage your config and schema

So _default considered unsafe? :) On Tue, Nov 3, 2020 at 11:08 AM Erick Erickson wrote: > > The caution I would add is that you should be careful > that you don’t enable schemaless mode without understanding > the consequences in detail. > > There is, in fact, some discussion of removing

Re: Solr migration related issues.

You absolutely need core.properties files. It’s just that they should be considered an “implementation detail” that you should rarely, if ever need to be aware of. Scripting manual creation of core.properties files in order to define your collections has never been officially supported, it just

Re: how do you manage your config and schema

The caution I would add is that you should be careful that you don’t enable schemaless mode without understanding the consequences in detail. There is, in fact, some discussion of removing schemaless entirely, see: https://issues.apache.org/jira/browse/SOLR-14701 Otherwise, I usually

Re: Solr migration related issues.

Thanks Erick for your response. I will certainly use the APIs and not rely on the core.properties. I was going through the documentation on core.properties and found it to be still there. I have all the solr install scripts based on older Solr versions and wanted to re-use the same as the

how do you manage your config and schema

Yesterday I realized that we have been carrying forward our configs since, probably, 4.x days. I ran a config set action=create (from _default) and saw files i didn't recognize, and a lot *fewer* things than I've been uploading for the last few years. Anyway my new plan is to just use _default

Frequent Index Replication Failure in solr.

Hi team, We are having solr architecture as *master->repeater-> 3 slave servers.* We are doing incremental indexing on the master server(every 20 min) . Replication of index is done from master to repeater server(every 10 mins) and from repeater to 3 slave servers (every 3 hours). *We are facing

Re: Search issue in the SOLR for few words

There is not nearly enough information here to begin to help you. At minimum we need: 1> your field definition 2> the text you index 3> the query you send You might want to review: https://wiki.apache.org/solr/UsingMailingLists Best, Erick > On Nov 3, 2020, at 1:08 AM, Viresh Sasalawad >

Re: Solr migration related issues.

You’re relying on legacyMode, which is no longer supported. In older versions of Solr, if a core.properties file was found on disk Solr attempted to create the replica (and collection) on the fly. This is no longer true. Why are you doing it this manually instead of using the collections API?

Solr migration related issues.

Hi, I am migrating from Solr 6.5.1 to Solr 8.6.3. As a part of the entire upgrade I have the first task to install and configure the solr with the core and collection. The solr is installed in SolrCloud mode. In Solr 6.5.1 I was using the following key values in core.properties file. The

Solr.NestPathField

Hi: Use Solr.NestPathField to store data, SPLITSHARD is then used to shard the shard and it is found that the child's data is lost. Version 8.6.3