lucene-dev mailing list archives

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


Mark Harwood commented on LUCENE-1720:

Thanks for the updates, Shai.

Agreed on removing the treemap comment..
As you suggest, their may be a low-level accuracy timing issue under heavy load but for the
typically longer timeout settings we may set this is less likely to be an issue. 

Related: I did think of another feature for ATM - timeouts will typically be set to the maximum
bearable value that can be sustained by the hardware without upsetting lots of users/customers
who need answers.
This setting is therefore a tough business decision to make and is likely to be on the high
side to avoid annoying customers (10 seconds? 30?).
The current monitoring solution only aborts at the latest possible stage when the uppermost
acceptable limit has been reached and expensive resource has already been burned.
Maybe we could add a progress-testing method to ATM which can throw an exception earlier e.g.
    public void checkForProjectedActivityTimeout(float percentActivityCompletedSoFar)
Clients would need to estimate how far through a task they were and call this method periodically.

> 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