[
https://issues.apache.org/jira/browse/LUCENE-743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12533000
]
Yonik Seeley commented on LUCENE-743:
-------------------------------------
> I'm wondering about the case where once thread calls reopen while another
> thread is updating norms or deleting docs.
Hmmm there is cause for concern (and I should have had my mt-safe hat on :-)
Reopen is synchronized on the reader, and so are norms access and docs, but
from a quick look:
- reopen() may be synchronized, but clone() called on sub-readers isn't in a
synchronized context that the sub-reader cares about. For example,
MultiReader.reopen has the lock on the multireader, but calles
subreader.clone() which iterates over the norms in a non thread-safe way.
- IndexInput objects that are in use should never be cloned... (like what is
done in FieldsReader.clone())
> IndexReader.reopen()
> --------------------
>
> Key: LUCENE-743
> URL: https://issues.apache.org/jira/browse/LUCENE-743
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Index
> Reporter: Otis Gospodnetic
> Assignee: Michael Busch
> Priority: Minor
> Fix For: 2.3
>
> Attachments: IndexReaderUtils.java, lucene-743-take2.patch,
> lucene-743.patch, lucene-743.patch, lucene-743.patch, MyMultiReader.java,
> MySegmentReader.java, varient-no-isCloneSupported.BROKEN.patch
>
>
> This is Robert Engels' implementation of IndexReader.reopen() functionality,
> as a set of 3 new classes (this was easier for him to implement, but should
> probably be folded into the core, if this looks good).
--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
