[
https://issues.apache.org/jira/browse/LUCENE-6370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14382033#comment-14382033
]
Michael McCandless commented on LUCENE-6370:
--------------------------------------------
Thanks Dave.
I fear with the patch, ref counts on IndexReaders will run amuck?
Because, we incRef the original DirectoryReader (inside openIfChanged), but
later decRef the UninvertingReader?
But I'm baffled why you don't see problems (e.g. readers being closed while
still in use) when you use your patch.
Another simple option would be to make your own UninvertingSearcherManager that
overrides the necessary methods from the super class (there are not so many) to
do all operations on the same reader? ControlledRTReopenThread accepts any
ReferenceManager<T>...
> UninvertingReader cannot be used with ControlledRealTimeReopenThread
> --------------------------------------------------------------------
>
> Key: LUCENE-6370
> URL: https://issues.apache.org/jira/browse/LUCENE-6370
> Project: Lucene - Core
> Issue Type: Bug
> Affects Versions: 5.0
> Reporter: Dave Borowitz
> Attachments: LUCENE-6370.patch
>
>
> In order to sort over non-DocValues fields in 5.0 we need to use an
> UninvertingReader to get the old FieldCache behavior back. However,
> UninvertingReader cannot be (easily) used with a
> ControlledRealTimeReopenThread.
> Specifically, the easiest way to construct a ControlledRealTimeReopenThread
> is with a SearcherManager. The only way I found to wire an UninvertingReader
> into SearcherManager is to implement a SearcherFactory that wraps the
> passed-in reader. Unfortunately, that runs afoul of the check in
> SearcherManager.getSearcher that requires "SearcherFactory must wrap exactly
> the provided reader". So, as long as this check is there, I simply don't see
> a way to use UninvertingReader with NRT functionality.
> I think this is a serious issue for programs that need to be able to use NRT
> search features on indexes created with previous Lucene versions, for whom
> upgrading the index is not an easy option. If they were previously relying on
> sorting implicitly via FieldCache, the _only_ ways to upgrade are:
> a) rebuild the index using DocValues fields, or
> b) use UninvertingReader
> Right now there's a catch-22, as (a) is assumed to be not an option and (b)
> is broken due to this bug.
> I have a hacky workaround for Gerrit Code Review up for review here:
> https://gerrit-review.googlesource.com/#/c/66613/6/gerrit-lucene/src/main/java/com/google/gerrit/lucene/WrappableSearcherManager.java@191
> Basically, it loosens the restriction on the newSearcher result to allow
> Filtered{Directory,Leaf}Readers that wrap the original reader. This appears
> to work fine for us, and I don't see anything in UninvertingReader that would
> cause me to believe it doesn't work. However, I'm no expert on Lucene
> internals and I don't know why that identity check was there in the first
> place, so I may be missing something.
> Please do not take that patch directly until I have gotten permission from my
> employer to contribute it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
