lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yonik Seeley (JIRA)" <>
Subject [jira] Commented: (LUCENE-743) IndexReader.reopen()
Date Sun, 07 Oct 2007 20:09:50 GMT


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
- IndexInput objects that are in use should never be cloned... (like what is done in FieldsReader.clone())

> IndexReader.reopen()
> --------------------
>                 Key: LUCENE-743
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: Index
>            Reporter: Otis Gospodnetic
>            Assignee: Michael Busch
>            Priority: Minor
>             Fix For: 2.3
>         Attachments:, lucene-743-take2.patch, lucene-743.patch,
lucene-743.patch, lucene-743.patch,,, 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:
For additional commands, e-mail:

View raw message