lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LUCENE-3761) Generalize SearcherManager
Date Thu, 09 Feb 2012 17:44:04 GMT

    [ https://issues.apache.org/jira/browse/LUCENE-3761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13204681#comment-13204681
] 

Michael McCandless commented on LUCENE-3761:
--------------------------------------------

bq. do you think that NRTManager should be refactored too?

That would be wonderful!  It's rather... hairy.

But I think it's tricky, because the maybeReopen takes a boolean (applyDeletes)... which is
confusing.  Maybe, we can change this, so that you must specify the applyDeletes up front
to the ctor (I think there's no harm in making two NRTMgrs if you sometimes require deletes
and other times don't... I mean resource wise it'd be no different that what NRTManager now
does internally).  If we did that, then I think NRTManager could subclass ReferenceManager?
 (And would no longer "contain" a SearcherManager inside it).

Probably we should explore that on a new issue...
                
> Generalize SearcherManager
> --------------------------
>
>                 Key: LUCENE-3761
>                 URL: https://issues.apache.org/jira/browse/LUCENE-3761
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: core/search
>            Reporter: Shai Erera
>            Assignee: Shai Erera
>            Priority: Minor
>             Fix For: 3.6, 4.0
>
>         Attachments: LUCENE-3761.patch, LUCENE-3761.patch
>
>
> I'd like to generalize SearcherManager to a class which can manage instances of a certain
type of interfaces. The reason is that today SearcherManager knows how to handle IndexSearcher
instances. I have a SearcherManager which manages a pair of IndexSearcher and TaxonomyReader
pair.
> Recently, few concurrency bugs were fixed in SearcherManager, and I realized that I need
to apply them to my version as well. Which led me to think why can't we have an SM version
which is generic enough so that both my version and Lucene's can benefit from?
> The way I see SearcherManager, it can be divided into two parts: (1) the part that manages
the logic of acquire/release/maybeReopen (i.e., ensureOpen, protect from concurrency stuff
etc.), and (2) the part which handles IndexSearcher, or my SearcherTaxoPair. I'm thinking
that if we'll have an interface with incRef/decRef/tryIncRef/maybeRefresh, we can make SearcherManager
a generic class which handles this interface.
> I will post a patch with the initial idea, and we can continue from there.

--
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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message