[
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
Attaching a revised version of the patch to fix the random NRT failures.
The first version of the patch actually made the failure *more* likely on my
system. I saw two failures, each within a few hundred iterations.
(Separately, I did finally get the test to fail on the unpatched code, after
roughly 10k iterations.)
This version of the patch is a superset of the first version of the patch. It
adds synchronized sections around pulling a searcher from, and reassigning, the
{{searcherMgr}}. My theory is that when one thread is executing
{{ensureOpen()}} and closes the {{searcherMgr}}, but then before the
{{searcherMgr}} is reassigned in this thread, another thread attempts an
{{acquire()}} on the now-closed {{searcherMgr}}. The {{synchronized}} sections
added in this version of the patch cause {{acquire()}} calls to wait until
{{searcherMgr}} has finished being reassigned. Since {{searcherMgr.release()}}
is tolerant of being called after {{close()}} has been called, I didn't include
the whole acquire/release cycle in the {{synchronized}} sections.
I saw no failures with this patch after 2000 beasting iterations. I also
beasted {{BlendedInfixSuggesterTest}} for 2000 iterations, and saw no failures
there either.
I think this is ready to go. I'll commit shortly.
> 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-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: [email protected]
For additional commands, e-mail: [email protected]
