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

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

bq. Maybe we can benchmark this approach

See 
http://www.nabble.com/Improving-TimeLimitedCollector-td24174758.html#a24229185
The figures were produced by TestTimeLimitedIndexReader that is part of this 
Jira issue so you can try benchmarks on your own indexes.

bq.if it slows down queries due to the the Thread.currentThread and hash lookup

This lookup only happens when threads start or stop timed activities and when 
there is a timed out state - all other method invocations on 
TimeLimitedIndexReader eg termDocs.next() are simply testing a volatile boolean 
which is used to indicate if any timeout has occurred. This seems to be fast in 
my benchmarks.

bq. maybe we can .. change the Lucene API such that we pass in an argument to 
the IndexReader methods where the timeout may be checked 

The current design uses static methods which remove the need to pass a timeout 
object as context everywhere but using this approach comes with the downside 
that a single client thread is unable to time >1 activity at once which we 
thought was a reasonable trade-off. See 
http://www.nabble.com/Re%3A-Improving-TimeLimitedCollector-p24234976.html

> 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