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

Mark Harwood commented on LUCENE-1720:
--------------------------------------

Currently the class hinges on a "fast fail" mechanism whereby all the many 
calls checking for a timeout are very quickly testing a single volatile 
boolean, "anActivityHasTimedOut".
99.99% of calls are expected to fail this test (nothing has timed out) and fail 
quickly - I was reluctant to add any hashset lookup etc in there needed to 
determine failure.

With that as a guiding principle maybe the solution is to change
    volatile boolean anActivityHasTimedOut
into
    volatile int numberOfTimedOutThreads;

which would cater for >1 error condition at once. The fast-fail check then 
becomes:
    if(numberOfTimedOutThreads > 0)
    {
         if(timedoutThreads.contains(Thread.currentThread)
         { 
            timedoutThreads.remove(Thread.currentThread);
            numberOfTimedOutThreads=timedoutThreads.size();
            throw RuntimeException.....
         }
   }




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

Reply via email to