lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shai Erera (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LUCENE-3486) Add SearcherLifetimeManager, so you can retrieve the same searcher you previously used
Date Tue, 04 Oct 2011 19:33:34 GMT

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

Shai Erera commented on LUCENE-3486:
------------------------------------

What a cool object, Mike ! And the javadocs are very good too.

* Perhaps instead of "recordTimeSec = System.nanoTime()/1000000000.0;" you can use TimeUnit.NANOS.toSeconds?
Just for clarity, and get rid of this monstrous number :).

* Typo: "such that if the use performs": 'use' --> 'user'

* About this code:
{code}
+    if (tracker == null) {
+      tracker = new SearcherTracker(searcher);
+      if (searchers.putIfAbsent(version, tracker) != null) {
+        // Another thread beat us -- must decRef to undo
+        // incRef done by SearcherTracker ctor:
+        searcher.getIndexReader().decRef();
+      }
{code}
Would it be better if SearcherTracker has a close() method and we call it instead of decRef()-ing
on our own? Seems cleaner to me, and I always like to see the code that incRef/new closer
to decRef/close. And if tomorrow SearcherTracker needs to clear other things too, we're already
covered.

* About this "// nocommit -- maybe make it 'public' that you just decRef?" --> do you mean
whether we should jdoc that that's all we're doing? If so, why commit to just that? I don't
think it contributes to the user ...

* I have a problem with the Pruner interface. It has a single method prune which takes an
IndexSearcher and ageSec (BTW, why is it double and not long?). And there's PruneByAge impl.
But, what other impls could there be for this interface, if not by age?
** On the other hand, I can certainly see someone, perhaps w/ NRT, not wanting to keep too
many searchers around, and instead of committing to an age, he'll want to use a hard number
(like, the newest 5 searchers) - that interface makes it impossible to impl.

If you think however that pruning by age, is the only scenario that makes sense, then I suggest
removing the interface and having just the impl. Otherwise, perhaps a different interface
should be created, one that receives a list of searchers, with their age, and returns a list
of searchers that should be released? Just an idea.

Hmm, now that I read prune(Pruner) jdoc, I can see how someone could impl "newest 5 searchers"
by just counting up to 5 in its doPrune() calls, because prune(Pruner) guarantees that the
searchers are passed newest to oldest. But still I wonder if the interface is not too limited.

Looks very good !
                
> Add SearcherLifetimeManager, so you can retrieve the same searcher you previously used
> --------------------------------------------------------------------------------------
>
>                 Key: LUCENE-3486
>                 URL: https://issues.apache.org/jira/browse/LUCENE-3486
>             Project: Lucene - Java
>          Issue Type: New Feature
>          Components: core/search
>            Reporter: Michael McCandless
>            Assignee: Michael McCandless
>             Fix For: 3.5, 4.0
>
>         Attachments: LUCENE-3486.patch
>
>
> The idea is similar to SOLR-2809 (adding searcher leases to Solr).
> This utility class sits above whatever your source is for "the
> current" searcher (eg NRTManager, SearcherManager, etc.), and records
> (holds a reference to) each searcher in recent history.
> The idea is to ensure that when a user does a follow-on action (clicks
> next page, drills down/up), or when two or more searcher invocations
> within a single user search need to happen against the same searcher
> (eg in distributed search), you can retrieve the same searcher you
> used "last time".
> I think with the new searchAfter API (LUCENE-2215), doing follow-on
> searches on the same searcher is more important, since the "bottom"
> (score/docID) held for that API can easily shift when a new searcher
> is opened.
> When you do a "new" search, you record the searcher you used with the
> manager, and it returns to you a long token (currently just the
> IR.getVersion()), which you can later use to retrieve the same
> searcher.
> Separately you must periodically call prune(), to prune the old
> searchers, ideally from the same thread / at the same time that
> you open a new searcher.

--
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