[ https://issues.apache.org/jira/browse/LUCENE-3793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13420504#comment-13420504 ]
Shai Erera commented on LUCENE-3793: ------------------------------------ Noticed that TestTaxonomyCombined has an ignored testTaxonomyReaderRefreshRaces. I think this issue will solve the problem described there, so noting here to enable the test as part of this issue, to verify. > Use ReferenceManager in DirectoryTaxonomyReader > ----------------------------------------------- > > Key: LUCENE-3793 > URL: https://issues.apache.org/jira/browse/LUCENE-3793 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/facet > Reporter: Shai Erera > Assignee: Shai Erera > Priority: Minor > Fix For: 4.1 > > > DirTaxoReader uses hairy code to protect its indexReader instance from > being modified while threads use it. It maintains a ReentrantLock > (indexReaderLock) which is obtained on every 'read' access, while > refresh() locks it for 'write' operations (refreshing the IndexReader). > Instead of all that, now that we have ReferenceManager in place, I think > that we can write a ReaderManager<IndexReader> which will be used by > DirTR. Every method that requires access to the indexReader will > acquire/release (not too different than obtaining/releasing the read > lock), and refresh() will call ReaderManager.maybeRefresh(). It will > simplify the code and remove some rather long comments, that go into > great length explaining why does the code looks like that. > This ReaderManager cannot be used for every IndexReader, because DirTR's > refresh() logic is special -- it reopens the indexReader, and then > verifies that the createTime still matches on the reopened reader as > well. Otherwise, it closes the reopened reader and fails with an exception. > Therefore, this ReaderManager.refreshIfNeeded will need to take the > createTime into consideration and fail if they do not match. > And while we're at it ... I wonder if we should have a manager for an > IndexReader/ParentArray pair? I think that it makes sense because we > don't want DirTR to use a ParentArray that does not match the IndexReader. > Today this can happen in refresh() if e.g. after the indexReader instance > has been replaced, parentArray.refresh(indexReader) fails. DirTR will be > left with a newer IndexReader instance, but old (or worse, corrupt?) > ParentArray ... I think it'll be good if we introduce clone() on ParentArray, > or a new ctor which takes an int[]. > I'll work on a patch once I finish with LUCENE-3786. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org