[
https://issues.apache.org/jira/browse/SOLR-9712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yonik Seeley updated SOLR-9712:
-------------------------------
Attachment: SOLR-9712.patch
Here's a completely untested patch.
It's much smaller than it looks (change in indentation obscures actual changes.)
This really just adds a loop around the open logic and then replaces the code
that throws an exception when maxWarmingSearchers is exceeded with a wait.
Seems like the lowest risk change since it doesn't change anything else.
{code}
} else if (onDeckSearchers > maxWarmingSearchers) {
onDeckSearchers--;
try {
searcherLock.wait();
} catch (InterruptedException e) {
log.info(SolrException.toStr(e));
// TODO: should we throw an exception in this case?
}
continue; // go back to the top of the loop and retry
{code}
That code just logs an InterruptedException, but perhaps we should throw an
exception in that case (i.e. abort trying to open a reader)? Things like this
sometimes do have a real impact on our Chaos tests though...
> Saner default for maxWarmingSearchers
> -------------------------------------
>
> Key: SOLR-9712
> URL: https://issues.apache.org/jira/browse/SOLR-9712
> 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
>
>
> 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
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
