lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shai Erera (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LUCENE-1720) TimeLimitedIndexReader and associated utility class
Date Mon, 29 Jun 2009 13:43:47 GMT

    [ https://issues.apache.org/jira/browse/LUCENE-1720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12725172#action_12725172
] 

Shai Erera commented on LUCENE-1720:
------------------------------------

bq. ... quickly testing a single volatile boolean, "anActivityHasTimedOut".

Oh, I did not mean to skip this check. After anActivityHasTimedOut is true, instead of comparing
Thread.currentThread() to firstAnticipatedThreadToFail, check if Thread.currentThread() is
in the failed HashSet of threads, or something like that.

I totally agree this should be kept and used that way, and it's probably better than numberOfTimedOutThreads
since we don't need to inc/dec the latter every failure, just set a boolean flag and test
it.

bq. Imo, the problem can be reformulated as "Provide possibility to cancel running queries
on best effort basis, with or without providing so far collected results".

That's where we started from, but Mark here wanted to provide a much more generalized way
of stopping any other activity, not just search. With this utility class, someone can implement
a TimeLimitedIndexWriter which times out indexing, merging etc. Search is just one operation
which will be covered as well.

I also think that TimeLimitingCollector already provides a possibility to "cancel running
queries on a best effort basis" and therefore if someone is interested in just that, he doesn't
need to use TimeLimitedIndexReader. However this approach seems much more simple if you want
to ensure queries are stopped ASAP, w/o passing a Timeout object around or anything. This
approach also guarantees (I think) that any custom Scorer which does a lot of work, but uses
IndexReader for that, will be stopped, even if the Scorer's developer did not implement a
Timeout mechanism. Right?

> TimeLimitedIndexReader and associated utility class
> ---------------------------------------------------
>
>                 Key: LUCENE-1720
>                 URL: https://issues.apache.org/jira/browse/LUCENE-1720
>             Project: Lucene - Java
>          Issue Type: New Feature
>          Components: Index
>            Reporter: Mark Harwood
>            Assignee: Mark Harwood
>            Priority: Minor
>         Attachments: ActivityTimedOutException.java, ActivityTimeMonitor.java, TestTimeLimitedIndexReader.java,
TimeLimitedIndexReader.java
>
>
> 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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message