lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless (Commented) (JIRA)" <>
Subject [jira] [Commented] (LUCENE-3486) Add SearcherLifetimeManager, so you can retrieve the same searcher you previously used
Date Tue, 04 Oct 2011 21:15:34 GMT


Michael McCandless commented on LUCENE-3486:

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

I was wanting to have the seconds be a double, but, I agree that's
overkill; I think a "typical" pruning time should be maybe 10 minutes
and so having "int seconds" is OK.  I'll change it and use

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

Thanks I'll fix.

bq. Would it be better if SearcherTracker has a close() method and we call it instead of decRef()-ing
on our own?

I agree -- I'll fix.

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

Well... the release is sort of "spooky" in that you can freely call it after close, which
is why I thought about making its impl public; but I agree, let's leave it private and just
keep the NOTE that it's fine to call after close.

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.

Right, my idea was to make it really easy to prune-by-age, since
that's the common case, but also make it possible to do more
expert policies.

I think prune-by-count is possible, but maybe more interesting would
be prune-by-total-segments-size, ie, if a large merge commits, this
metric would cut back on the number of searchers so that the net RAM
tied up is lower.  Not sure this is really needed in practice as large
merges don't complete often and it's unlikely you'd hit more than one in
your time window...

Thanks Shai!

> Add SearcherLifetimeManager, so you can retrieve the same searcher you previously used
> --------------------------------------------------------------------------------------
>                 Key: LUCENE-3486
>                 URL:
>             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:!default.jspa
For more information on JIRA, see:


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

View raw message