RE: Solr node goes into recovery mode

Thanks for reply. Our solr node normally uses 30-45 gb and hence we allocated 60 heap size. We analyzed heap dump and found that around 85% heap was used by org.apache.solr.uninverting.FieldCacheImpl. One instance of "org.apache.solr.uninverting.FieldCacheImpl" loaded by "

query keyword but no result (solr 8)

Hi, I am trying to setup solrcloud, I can index a few documents successfully. but I cannot get result if I search keyword(without field). if I use field:keyword, I can get result. any idea why I get this issue? Thank you -- Regards, Derrick Cui Email: derrick...@gmail.com

Re: Solr node goes into recovery mode

On 5/13/2019 8:26 AM, Maulin Rathod wrote: Recently we are observing issue where solr node (any random node) automatically goes into recovery mode and stops responding. Do you KNOW that these Solr instances actually need a 60GB heap? That's a HUGE heap. When a full GC happens on a heap that

Re: Solr node goes into recovery mode

There are a number of timeouts that can trip this, the ZK timeout is only one. For instance, when a leader sends an update to a follower, if that times out the leader may put the follower into “Leader Iniated Recovery” (LIR). 60G heaps are, by and large, not recommended for this very reason. Co

Re: SolrCloud limitations?

Just an addendum to Erick's answer: you can see also the possibility of using different replica types like TLOG or PULL. It will depend on your use case and performance requirements. See https://lucene.apache.org/solr/guide/7_7/shards-and-indexing-data-in-solrcloud.html Best, Edward On Mon, May 1

Re: Softer version of grouping and/or filter query

Cool! Paraphrasing 'Solr in Action' book: edismax is the query parser to use when dealing with users' queries. It has a lot of customization options and is more resilient to ill-formed queries than lucene-parser. Whenever possible, take some time to dig deeper into those. :) Regards, Edward On Fr

Solr node goes into recovery mode

Hi, We are using solr 6.1 version with 2 shards. Each shard have 1 replica set-up. i.e. We have total 4 server nodes (each node is assigned 60 gb of RAM). Recently we are observing issue where solr node (any random node) automatically goes into recovery mode and stops responding. We have enoug

Re: Solr query takes a too much time in Solr 6.1.0

On 5/13/2019 2:51 AM, vishal patel wrote: Executing an identical query again will likely satisfy the query from Solr's caches. Solr won't need to talk to the actual index, and it will be REALLY fast. Even a massively complex query, if it is cached, will be fast. All caches are disabled in o

Spellcheck Collations Phrase based instead of AND

Hi, For a sample collation during spellcheck. "collation",{ "collationQuery":"smart connected factory", "hits":109, "misspellingsAndCorrections":[ "smart","smart", "connected","connected", "fator","factory"]}, "collation",{ "co

Re: SolrCloud limitations?

There’s no a-priori limit. 12 or 15 servers will be fine. As add more and more replicas, there’s a little overhead at indexing time to get all the docs distributed from the leader to all replicas. I’ve seen 100s of replicas for a given shard. Best, Erick > On May 13, 2019, at 12:18 AM, Juerge

Re: Solr 8.0.0 error: cannot change field from index options=DOCS to inconsistent index options=DOCS_AND_FREQS_AND_POSITIONS

Whenever you change a field’s type, reindexing is usually indicated. There are a very few times when it’s not. This really has nothing to do with 8.0, just the fact that you want to change the field’s type. Do be aware that if the index was _ever_ touched by a 6x version of Lucene, you must re-

Re: Solr query takes a too much time in Solr 6.1.0

Oh, and you can freely set docValues=true _and_ have indexed=true on the same field, Solr will use the right structure for the operations it needs. HOWEVER: if you change that definition you _must_ re-index the entire collection. > On May 13, 2019, at 1:22 AM, Bernd Fehling > wrote: > > Your

Re: Solr query takes a too much time in Solr 6.1.0

That indicates you’re hitting the queryResultCache, which is also supported by your statement about how fast queries are returned after they’re run once. Look at admin UI>>select core>>stats/plugins>>cache>>queryResultCache and you’ll probably see a very hit ratio, approaching 1. You also have

Re: Solr query takes a too much time in Solr 6.1.0

In our live environment, there are many searching and indexing within a millisecond. we used facet and sorting in Query. > 3. To speedup sorting have a separate field with docValues=true for sorting. Is it necessary or useful to make a separate field if I used this field in sorting or facet? If

Shard got down in Solr 6.1.0

vishal patel has shared a OneDrive file with you. To view it, click the link below. [https://r1.res.office365.com/owa/prem/images/dc-txt_20.png] GC_log.txt

Re: Solr query takes a too much time in Solr 6.1.0

Thanks for the reply. > Executing an identical query again will likely satisfy the query from Solr's > caches. Solr won't need to talk to the actual index, and it will be REALLY > fast. Even a massively complex query, if it is cached, will be fast. All caches are disabled in our schema file b

Re: Streaming Expression: get the value of the array at the specified position

That was really helpful for my use case. It should definitely be included in the documentation. On Sat, May 11, 2019 at 8:19 PM Joel Bernstein wrote: > There actually is an undocumented function called valueAt. It works both > for an array and for a matrix. > > For an array: > > let(echo="b", a

Invalid Date Math Strings silently fail in q, not in fq

Hello, I encountered an issue where invalid dates throw an exception when they are in an fq parameter but are silently dropped when in q. For example: { "responseHeader":{ "zkConnected":true, "status":0, "QTime":4, "params":{ "q":"visible_date:[2019-01-01T00:00:00Z TO 2019

Re: Solr 8.0.0 error: cannot change field from index options=DOCS to inconsistent index options=DOCS_AND_FREQS_AND_POSITIONS

OK, so the problem seems to come from https://issues.apache.org/jira/browse/LUCENE-8134 Our field used to be type="string", but we have since changed it to a text type to be able to use synonyms (see below). So we'll still have some documents that were indexed as "string". Am I right in assuming t