lucene-dev mailing list archives

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


Shai Erera updated LUCENE-1720:

    Attachment: LUCENE-1720.patch

Collected all the files in the issue into a single .patch file. I also included the following
# Formatting.
# Renamed TestTimeLimitedIndexReader to TimeLimitedIndexReaderBenchmark - I don't want it
to be run by ant test. We should review it anyway and put in in benchmark.
# Created TestActivityTimeMonitor which tests the ATM itself. This revealed a bug in the ATM,
where it removed from the map while iterating on it (
#* BTW, the test testMultipleThreadsFailing() passes when the number of threads is 10, and
fails when it's set higher. It is definitely a timing issue, b/c if I change each thread to
sleep more than 200ms, the test passes. I suspect that when there are so many threads in the
system, TimeoutThread will not be as accurate. However I'm not sure if we should do something
about it ... if there are 50 threads running concurrently, things will be slow, and executing
search requests will take longer, therefore the TimeoutThread will have enough time to pick
their timeouts.

We need to create a test for the IndexReader case, I hope to get to it, but if you want, please
take a stab at 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