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

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

bq. Stop() removes a thread from 1) or 2)

Minor change - should be "from 1) and/or 2)". Actually I think the impl will 
always be "1) and 2)", i.e., we'll call remove() from both Map/Set w/o checking 
first if the Thread exists there.

bq. The monitoring thread has the job of moving items from 1) to 2) and waits 
for firstAnticipatedTimeout and is notify-ed if firstAnticipatedTimeout changes

I think here we'd want to keep a list (true "list") of timeouts, where 
firstAnticipatedTimeout = list.head() and if wait(firstAnticipatedTimeout) 
reaches, in addition to add that Thread to timedOutThread Set, also remove that 
timeout from the head of the list, and wait on the following expected timeout?

Perhaps all it means is that (1) should be a TreeMap, sorted by the expected 
timeout, and when the first timeout is reached, the thread is removed from (1) 
as its state is no longer indeterminate (i.e., we already know it has timed 
out)?

> 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