You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Shai Erera (Updated) (JIRA)" <ji...@apache.org> on 2012/02/08 17:56:59 UTC
[jira] [Updated] (LUCENE-3761) Generalize SearcherManager
[ https://issues.apache.org/jira/browse/LUCENE-3761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Shai Erera updated LUCENE-3761:
-------------------------------
Attachment: LUCENE-3761.patch
Initial patch. Introduces a new package 'thingy' (a temporary one, this will eventually move to o.a.l.search) with the class ThingyManager, a Thingy interface and a SearcherThingy implementation.
As far as I can tell (if there are no bugs), this can replace SearcherManager as-is, aside from a 'nocommit' which I know how to handle, but didn't get to it yet.
The approach is that ThingyManager receives a Thingy<G> instance and delegates calls to it.
Robert and I discussed another approach - have ThingyManager abstract with a concrete (final) SearcherManager impl which overrides methods like incRef/decRef etc. I still didn't try to impl that approach, I think that I'll give it a try, later.
Oh, and BTW, ThingyManager (even though a cool name !) will not be its final name ! :). It's just easier to progress like that, without thinking too much about the name.
> 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
>
>
> 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