[
https://issues.apache.org/jira/browse/LUCENE-1720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12832491#action_12832491
]
Shai Erera commented on LUCENE-1720:
------------------------------------
bq. We can always provide a convenience wrapper method which throws an
exception : ATM.blowUpIfNotGoingFastEnough(float progress)
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:
{code}
if (!ATM.checkProjectedTimeoutOnThisThread(progress)) {
throw new ActivityTimedOutException("terminating due to projected timeout.
progress = " + progress);
}
{code}
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: 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, ActivityTimeMonitor.java, ActivityTimeMonitor.java,
> LUCENE-1720.patch, TestTimeLimitedIndexReader.java,
> TestTimeLimitedIndexReader.java, TimeLimitedIndexReader.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: [email protected]
For additional commands, e-mail: [email protected]
