lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shai Erera (Commented) (JIRA)" <>
Subject [jira] [Commented] (LUCENE-3776) NRTManager shouldn't expose its private SearcherManager
Date Fri, 17 Feb 2012 15:29:59 GMT


Shai Erera commented on LUCENE-3776:

Looks good Mike.

Do we still need that assert, now that getSearcher() checks that the returned IR is the one
it passed to SearcherFactory? I think it covers the case the returned IR is also a DirReader?

assert r instanceof DirectoryReader: "searcher's IndexReader should be a DirectoryReader,
but got " + r;

I noticed that NRTManager shares some logic with SearcherManager (e.g. getSearcher) -- is
there a way to avoid the duplication? Maybe if getSearcher would be a package-private static
method on SM?

These are not critical IMO, so I'll leave the decision on whether to fix or not to you. +1
to commit.
> NRTManager shouldn't expose its private SearcherManager
> -------------------------------------------------------
>                 Key: LUCENE-3776
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Improvement
>            Reporter: Michael McCandless
>            Assignee: Michael McCandless
>            Priority: Blocker
>             Fix For: 3.6, 4.0
>         Attachments: LUCENE-3776.patch, LUCENE-3776.patch, LUCENE-3776.patch
> Spinoff from LUCENE-3769.
> To actually obtain an IndexSearcher from NRTManager, it's a 2-step process now.
> You must .getSearcherManager(), then .acquire() from the returned SearcherManager.
> This is very trappy... because if the app incorrectly calls maybeReopen on that private
SearcherManager (instead of NRTManager.maybeReopen) then it can unexpectedly cause threads
to block forever, waiting for the necessary gen to become visible.  This will be hard to debug...
I don't like creating trappy APIs.
> Hopefully once LUCENE-3761 is in, we can fix NRTManager to no longer expose its private
SM, instead subclassing ReferenceManaager.
> Or alternatively, or in addition, maybe we factor out a new interface (SearcherProvider
or something...) that only has acquire and release methods, and both NRTManager and ReferenceManager/SM
impl that, and we keep NRTManager's SM private.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message