Re: Cause of java.io.IOException: No space left on device Error

Hello, Community: Thank you for replying to my email. Your responses were very helpful. 2020年4月23日(木) 20:35 Erick Erickson : > In addition to what Dario mentioned, background merges > happen all the time, optimize is just a special case (and > very expensive). > > You say “one of my Solr

Re: Defaults Merge Policy

Thank you for responding. I will keep your words in mind. Thank you again. 2020年4月23日(木) 20:38 Erick Erickson : > Glad those articles helped, I remember them well ;) > > Do note that 30 (well, actually 33%) is usually the ceiling. > But as I mentioned, it’s soft, not absolute. So your index >

Re: Unbalanced shard requests

Hi Eric, I am measuring the number of shard requests, and it's for query only, no indexing requests. I have an external load balancer and see each node received about the equal number of external queries. However for the internal shard queries, the distribution is uneven:6 nodes (one in

Re: Unbalanced shard requests

Wei: How are you measuring utilization here? The number of incoming requests or CPU? The leader for each shard are certainly handling all of the indexing requests since they’re TLOG replicas, so that’s one thing that might skewing your measurements. Best, Erick > On Apr 27, 2020, at 7:13 PM,

Unbalanced shard requests

Hi everyone, I have a strange issue after upgrade from 7.6.0 to 8.4.1. My cloud has 6 shards with 10 TLOG replicas each shard. After upgrade I noticed that one of the replicas in each shard is handling most of the distributed shard requests, so 6 nodes are heavily loaded while other nodes are

Re: Reindexing using dataimporthandler

You’re welcome. Solr is a huge beast, I don’t think any single individual knows all the bits and pieces… Or, in my case, can remember them ;) > On Apr 27, 2020, at 9:15 AM, Bjarke Buur Mortensen > wrote: > > Wow, thanks. Erick. That's actually much better :-) > You live and you learn. > >

Re: Reindexing using dataimporthandler

Wow, thanks. Erick. That's actually much better :-) You live and you learn. Cheers, Bjarke Den man. 27. apr. 2020 kl. 15.00 skrev Erick Erickson < erickerick...@gmail.com>: > What about the Collections API REINDEXCOLLECTION? That has the > advantage of being something officially supported, puts

Re: Reindexing using dataimporthandler

What about the Collections API REINDEXCOLLECTION? That has the advantage of being something officially supported, puts the source collection into read-only mode, uses a much more efficient query process (streaming actually) etc. It has the disadvantage of producing a new collection under the

Re: Reindexing using dataimporthandler

Thanks for the reply, I'm on solr 8.2 so cursorMark is there. Doing this from one collection to another collection, and then use a collection alias is probably the way to go, but actually, my suggestion was a little more bold: I'm indexing on top of the same core, i.e from

Re: Reindexing using dataimporthandler

Hi Bjarke, I don’t see a problem with that approach if you have enough resources to handle both cores at the same time, especially if you are doing that while serving production queries. The only issue is that if you plan to do that then you have to have all fields stored. Also note that

Reindexing using dataimporthandler

Hi list, Let's say I add a copyField to my solr schema, or change the analysis chain of a field or some other change. It seems to me to be an alluring choice to use a very simple dataimporthandler to reindex all documents, by using a SolrEntityProcessor that points to itself. I have just done

RE: IdleTimeout setting in Jetty (Solr 7.7.1)

Can someone shed some idea on below requirement? Thanks & Regards, Vinodh From: Kommu, Vinodh K. Sent: Friday, April 24, 2020 11:34 PM To: solr-user@lucene.apache.org Subject: IdleTimeout setting in Jetty (Solr 7.7.1) Hi, Our clients are running streaming expressions on 140M docs collection