lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shai Erera (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LUCENE-1720) TimeLimitedIndexReader and associated utility class
Date Thu, 02 Jul 2009 08:40:47 GMT

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


Mime
View raw message