[
https://issues.apache.org/jira/browse/LUCENE-6370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14382956#comment-14382956
]
Michael McCandless commented on LUCENE-6370:
--------------------------------------------
Hmm, I see. The original DirectoryReader (from DirectoryReader.open, or that
you passed into SearcherManager's ctor) has a +1 ref count, that I'm not sure
ever gets decRef'd because we decRef getSearcher(searcherFactory,
reader).getIndexReader() (the wrapped reader)?
However, that decRef won't result in over-decRef, I think, because it has a +1
ref count from when the wrapped reader was created?
So maybe it's only the first originally opened (not wrapped) DirectoryReader
that will have an extra refCount? Maybe double check that all file descriptors
are in fact being closed?
Is your wrapped reader a new DirectoryReader where you wrapped each leaf in
UninvertingReader?
bq. Except in the failure case from getSearcher--should that be changed to
wrapped.decRef() perhaps?
Hmm but searcher may not be initialized, if the exc happened inside
newSearcher? Also, with the check as it is now, reader ==
searcher.getIndexReader().
> 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]
