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

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

bq. When's this ready to test with Solr?

I think the API is pretty stable - call try..start..finally...stop around 
time-critical stuff and use a TimeLimitedIndexReader to wrap your IndexReader.

Internally the implementation feels reasonably stable too.

In my tests it doesn't seem to add too much overhead to calls -  I was getting 
response times of 3400 milliseconds on a heavy wikipedia query with 
TimeLimitedIndexReader versus 3300 for the same query on a raw IndexReader 
without timeout protection.

I'm tempted to try put the timeout check calls directly into a version of 
IndexReader rather than in a delegating reader wrapper just to try see if the 
wrapper code is where the bulk of the extra overhead comes in. I'd hate to add 
any overhead to core IndexReader but I'm keen to see just how low-cost this 
check can get.

> 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, 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