[
https://issues.apache.org/jira/browse/LUCENE-6370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14382195#comment-14382195
]
Dave Borowitz commented on LUCENE-6370:
---------------------------------------
I think we might be ok on refcounts? Here's my thinking.
SearcherManager.refreshIfNeeded calls DirectoryReader.openIfChanged on the
result of referenceToRefresh.getIndexReader(). But I think that particular
IndexReader is always the UninvertingReader, or more precisely, the result of
getSearcher(searcherFactory, reader).getIndexReader(). I don't think we ever
touch the refcount of the original reader. (Except in the failure case from
getSearcher--should that be changed to wrapped.decRef() perhaps?)
> 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]
