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

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

Liked the formatting. Didn't know you can do that :).

This looks good. About throwing the exception, it bothers me that we decide for 
the caller that if the task is expected to timeout, we terminate it. Maybe 
someone will want to give it another try, and really timeout if the projection 
failed for a couple of times? So for this I think we either throw a different 
exception, or return a boolean which I prefer better. The caller can then 
decide what to do if the method returned false ... what do you think?
I'm thinking that unlike checkForTimeout which is definite - if it 'returns' 
true you need to terminate, checking for the projected timeout is different, 
more intentional and 'test' in nature, so let's be more forgiving with it?

About TimeLimitingCollector, I think the usage does not allow to reuse 
TimeAcitivityMonitor? i.e., w/ ATM you need to start and stop, but the 
collector cannot stop (it can start in the ctor, which is not good either since 
that may be 'too far' from collect()). Even though it's not critical for a 
thread to remain in the timeLimitedThreads map (because if the thread is 
reused, next time start() is called it will override itself in the map), the 
TimeoutThread will falsely signal that a timeout has occurred. Doesn't feel 
right to me.

> 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

Reply via email to