[ 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: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org