[
https://issues.apache.org/jira/browse/LUCENE-1726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12727813#action_12727813
]
Michael McCandless commented on LUCENE-1726:
--------------------------------------------
The hazard is something like this, for a non-NRT IndexWriter (ie, no
pooling):
* Thread #1 is a merge; it checks out a reader & starts running
* Thread #2 is applyDeletes (or opening an NRT reader); it calls
readerPool.get, enters the first sync block to pull out the
SRMapValue which has non-null reader, then leaves the sync block
* Thread #1 calls release, which decRefs the reader & closes it
* Thread #2 resumes, sees it has a non-null mv.reader and incRefs
it, which is illegal (reader was already closed).
> IndexWriter.readerPool create new segmentReader outside of sync block
> ---------------------------------------------------------------------
>
> Key: LUCENE-1726
> URL: https://issues.apache.org/jira/browse/LUCENE-1726
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Index
> Affects Versions: 2.4.1
> Reporter: Jason Rutherglen
> Assignee: Michael McCandless
> Priority: Trivial
> Fix For: 3.1
>
> Attachments: LUCENE-1726.patch, LUCENE-1726.patch
>
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> I think we will want to do something like what field cache does
> with CreationPlaceholder for IndexWriter.readerPool. Otherwise
> we have the (I think somewhat problematic) issue of all other
> readerPool.get* methods waiting for an SR to warm.
> It would be good to implement this for 2.9.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
