I really think this is the wrong approach. bq: We do a commit on every update, but updates are very infrequent
I doubt this is actually true. You may think it is, but you just don't get more than 8 warming searchers in the situation you describe. Fix the _real_ problem here. Do what Hoss said. Look at your logs and examine the commits that happen just before you get this message. I pretty much guarantee that you will find a flurry of them in quick succession. Very quick succession. I claim you can get around this problem entirely by 1> setting your autocommit (hard, openSearcher=true) to 10 seconds. Which, btw, is very very low. I'd go with a minute or more myself, and also configure soft commits if you're on Solr 4 and really really care about latency. 2> never committing from the client. The reason I'm adamant about this is what you're doing will come back to bite you in the future if you don't fix the problem now. As you get more and more documents in the system, your 8 warming searchers will try to warm 8 versions of the caches you've configured in solrconfig.xml. If your index is very large, you'll hit OOM errors. Then you'll have to figure out why all over again. Really, with 37ms warming, you have a pathological situation that you need to understand and fix. Best, Erick On Thu, Sep 12, 2013 at 4:18 PM, gfbj <g...@excite.com> wrote: > I ended up having to do a mathematical increase of the delay > > <cfset sleep(1500+fileCount)> > > because the indexing eventually would outstrip the static value I set and > crash the maxWarmingSearchers. > > > > -- > View this message in context: > http://lucene.472066.n3.nabble.com/exceeded-limit-of-maxWarmingSearchers-tp489803p4089699.html > Sent from the Solr - User mailing list archive at Nabble.com. >
