lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Smiley (JIRA)" <>
Subject [jira] [Commented] (SOLR-9712) Saner default for maxWarmingSearchers
Date Fri, 16 Dec 2016 03:07:59 GMT


David Smiley commented on SOLR-9712:

This is wonderful and a big deal; thanks Yonik!  I didn't notice a CHANGES.txt in the patch,
so naturally you'll do that when you commit (I do the same approach).  If the CHANGES.txt
is no more clear than the title of this issue then users won't realize what this is all about,
I think.  Here's my attempt to word it:

bq. SOLR-9712: maxWarmingSearchers now defaults to 1, and more importantly commits will now
\*block\* if this limit is reached instead of throwing an error (a good thing).  Consequently
there is no longer a risk in overlapping commits.  Nonetheless users should continue to avoid
excessive committing.

> Saner default for maxWarmingSearchers
> -------------------------------------
>                 Key: SOLR-9712
>                 URL:
>             Project: Solr
>          Issue Type: Improvement
>      Security Level: Public(Default Security Level. Issues are Public) 
>          Components: search
>            Reporter: Shalin Shekhar Mangar
>             Fix For: master (7.0), 6.4
>         Attachments: SOLR-9712.patch, SOLR-9712.patch, SOLR-9712.patch
> As noted in SOLR-9710, the default for maxWarmingSearchers is Integer.MAX_VALUE which
is just crazy. Let's have a saner default. Today we log a performance warning when the number
of on deck searchers goes over 1. What if we had the default as 1 that expert users can increase
if needed?

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message