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 13:32:28 GMT


Shai Erera commented on LUCENE-1720:

Liked the formatting. Didn't know you can do that :).

This looks good. About throwing the exception, it bothers me that we decide for the caller
that if the task is expected to timeout, we terminate it. Maybe someone will want to give
it another try, and really timeout if the projection failed for a couple of times? So for
this I think we either throw a different exception, or return a boolean which I prefer better.
The caller can then decide what to do if the method returned false ... what do you think?
I'm thinking that unlike checkForTimeout which is definite - if it 'returns' true you need
to terminate, checking for the projected timeout is different, more intentional and 'test'
in nature, so let's be more forgiving with it?

About TimeLimitingCollector, I think the usage does not allow to reuse TimeAcitivityMonitor?
i.e., w/ ATM you need to start and stop, but the collector cannot stop (it can start in the
ctor, which is not good either since that may be 'too far' from collect()). Even though it's
not critical for a thread to remain in the timeLimitedThreads map (because if the thread is
reused, next time start() is called it will override itself in the map), the TimeoutThread
will falsely signal that a timeout has occurred. Doesn't feel right to me.

> 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