[
https://issues.apache.org/jira/browse/LUCENE-7564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Rowe updated LUCENE-7564:
-------------------------------
Attachment: LUCENE-7564-fix-random-NRT-failures.patch
After several thousand beasting iterations, I still haven't been able to
reproduce the {{testRandomNRT()}} failures.
I'm attaching a patch that I think will address the problem, which AFAICT is
that under multi-threaded use, in {{lookup()}}, the suggester’s {{searcherMgr}}
data member could be re-assigned in the middle of a searcher acquire/release
cycle due to the changes introduced in LUCENE-7564 - as a result these could be
imbalanced, with {{acquire()}} called on one instance and {{release()}} called
on a different one. The patch takes a local {{SearcherManager}} reference and
calls {{acquire()}}/{{release()}} though it in every place these are called in
{{AnalyzingInfixSuggester}} (rather than calling through the {{searcherMgr}}
data member).
I'm beasting {{AnalyzingInfixSuggester}} with this patch, and I'll commit later
today if there are no failures.
> AnalyzingInfixSuggester should close its IndexWriter by default at the end of
> build()
> -------------------------------------------------------------------------------------
>
> Key: LUCENE-7564
> URL: https://issues.apache.org/jira/browse/LUCENE-7564
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Steve Rowe
> Assignee: Steve Rowe
> Fix For: master (7.0), 6.4
>
> Attachments: LUCENE-7564-fix-random-NRT-failures.patch,
> LUCENE-7564.patch, LUCENE-7564.patch
>
>
> From SOLR-6246, where AnalyzingInfixSuggester's write lock on its index is
> causing trouble when reloading a Solr core:
> [~gsingers] wrote:
> bq. One suggestion that might minimize the impact: close the writer after
> build
> [~varunthacker] wrote:
> {quote}
> This is what I am thinking -
> Create a Lucene issue in which {{AnalyzingInfixSuggester#build}} closes the
> writer by default at the end.
> The {{add}} and {{update}} methods call {{ensureOpen}} and those who do
> frequent real time updates directly via lucene won't see any slowdowns.
> [~mikemccand] - Would this approach have any major drawback from Lucene's
> perspective? Else I can go ahead an tackle this in a Lucene issue
> {quote}
> [~mikemccand] wrote:
> bq. Fixing {{AnalyzingInfixSuggester}} to close the writer at the end of
> build seems reasonable?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
