[
https://issues.apache.org/jira/browse/SOLR-5386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris M. Hostetter updated SOLR-5386:
-------------------------------------
Attachment: SOLR-5386.patch
Assignee: Chris M. Hostetter
Status: Reopened (was: Reopened)
12 years later and this bug bites me in the ass – and the more i look at it,
the more embarrassed I am that we didn't fix this problem 10 years ago when the
root cause was clearly identified:
* Using {{maxCollationTries}} causes spellchecker to create sub requests
** these use {{LocalSolrQueryRequest}} which asks the {{SolrCore}} for the
latest register searcher (as well as the latest schema if it's mutable)
* asking {{SolrCore}} for the latest registered searcher block until at least
one registered searcher is available
** if a spellcheck query with {{maxCollationTries}} is invoked as part of
{{firstSearcher}} warming query, then a deadlock loop is introduced:
registering the first searcher is waiting on the spellcheck query, which is
waiting on the collation validation query which is waiting for the first
searcher to be registered
In the case of the original bug report:
* the default {{solrconfig.xml}} at the time had simple query (using the
default request handler) configured
* if/when you modified the default request handler to use spellchecking with
{{maxCollationTries}} you *might* (depending on the data in your index) get
suggested spellcheck collations for that warming query, and then you'd get
deadlock.
----
The fix seems really straight forward: spellcheck should not be using a "stock"
{{LocalSolrQueryRequest}} which asks the {{SolrCore}} for the latest register
searcher -- it should be using a "sub request" implementation of
{{SolrQueryRequest}} that is initialized with the same searcher (and current
schema) as the original request. (which in the case of warming is already
explicitly set to be the searcher being warmed)
I'm attaching a really straight forward patch that implements this by adding a
new {{subRequest()}} method to {{SolrQueryRequest}} for initializing a request
using the same core/schema/searcher as an existing request -- but with it's own
state. The patch also includes a new spellcheck test showing how attempting to
configured a {{firstSearcher}} warming query using {{maxCollationTries}} can
cause core reloading to deadlock the test -- but it passes with this change.
If there are no objections to this approach, i plan to flesh out the javadocs,
and audit other uses of {{LocalSolrQueryRequest}} to see where else in the code
base we should use this {{subRequest()}} method
> Solr hangs on spellcheck.maxCollationTries
> ------------------------------------------
>
> Key: SOLR-5386
> URL: https://issues.apache.org/jira/browse/SOLR-5386
> Project: Solr
> Issue Type: Bug
> Components: spellchecker
> Affects Versions: 4.5, 4.4
> Reporter: Jeroen Steggink
> Assignee: Chris M. Hostetter
> Priority: Major
> Labels: collate, maxCollationTries, spellcheck
> Attachments: SOLR-5386.patch, Solr5386SpellCheckerHangThreadDump.txt,
> threaddump.log
>
>
> When spellcheck.maxCollationTries is set (>0) Solr hangs in combination with
> that requestHandler set to default="true".
> When I make another requestHandler default, one without the
> maxCollationTries, all requestHandlers work just fine.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
