lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shai Erera (JIRA)" <>
Subject [jira] Commented: (LUCENE-1720) TimeLimitedIndexReader and associated utility class
Date Thu, 11 Feb 2010 14:12:28 GMT


Shai Erera commented on LUCENE-1720:

bq. We can always provide a convenience wrapper method which throws an exception : ATM.blowUpIfNotGoingFastEnough(float

Right. Although I'm thinking, in the sake of keeping the API simple, and back-compat sane,
it's easy enough for the caller to do:
if (!ATM.checkProjectedTimeoutOnThisThread(progress)) {
  throw new ActivityTimedOutException("terminating due to projected timeout. progress = "
+ progress);

bq. The first "collect"

Note: that means that every collect will need to check if it's the first.

I think we should leave TLC out of this for now. Maybe w/ TimeLimitingIndexReader, which has
finer granularity, TLC won't be used at all. At least, I definitely don't see why would one
use both...

About the packages, so we agree that ATM and exception move to o.a.l.util, and the reader
stay in index (like IndexReader)? And I don't think this warrants a contrib package, unless
we move TLC there as well. But this seems like a useful Lucene core utility.

So that we don't override each other - are you going to add the projected method to the patch?
If so, can you also order the packages and remove the TreeMap comment? If not I can do it.

> TimeLimitedIndexReader and associated utility class
> ---------------------------------------------------
>                 Key: LUCENE-1720
>                 URL:
>             Project: Lucene - Java
>          Issue Type: New Feature
>          Components: Index
>            Reporter: Mark Harwood
>            Assignee: Mark Harwood
>            Priority: Minor
>         Attachments:,,,, LUCENE-1720.patch,,,,
> An alternative to TimeLimitedCollector that has the following advantages:
> 1) Any reader activity can be time-limited rather than just single searches e.g. the
document retrieve phase.
> 2) Times out faster (i.e. runaway queries such as fuzzies detected quickly before last
"collect" stage of query processing)
> Uses new utility timeout class that is independent of IndexReader.
> Initial contribution includes a performance test class but not had time as yet to work
up a formal Junit test.
> TimeLimitedIndexReader is coded as JDK1.5 but can easily be undone.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

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

View raw message