[
https://issues.apache.org/jira/browse/LUCENE-1720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12832470#action_12832470
]
Mark Harwood commented on LUCENE-1720:
--------------------------------------
The change to ATM isn't that big - as you say just adding "start" to the data
on each thread.
Here's an (untested) example
{code:title=Bar.java|borderStyle=solid}
/**
* Checks to see if this thread is likely to exceed it's pre-determined
timeout.
* This is a heavier-weight call than "checkForTimeout" and should not
be called quite as frequently
*
* Throws {...@link ActivityTimedOutException}RuntimeException in the
event of any anticipated timeout.
* @param progress
*/
public static final void checkProjectedTimeoutOnThisThread(float
progress)
{
Thread currentThread=Thread.currentThread();
synchronized(timeLimitedThreads)
{
ActivityTime thisTimeOut =
timeLimitedThreads.get(currentThread);
if(thisTimeOut!=null )
{
long now=System.currentTimeMillis();
long
maxDuration=thisTimeOut.scheduledTimeout-thisTimeOut.startTime;
long durationSoFar=now-thisTimeOut.startTime;
float
expectedMinimumProgress=(float)durationSoFar/maxDuration;
if(progress<expectedMinimumProgress)
{
long expectedOverrun=(long)
(((durationSoFar*(1f-progress))+now)-thisTimeOut.scheduledTimeout);
throw new
ActivityTimedOutException("Thread "+currentThread+" is expected to time out,
estimated overrun ="
+expectedOverrun+ "
ms",expectedOverrun);
}
}
}
}
static class ActivityTime
{
public ActivityTime(long startTime, long timeOutTime)
{
this.startTime=startTime;
this.scheduledTimeout=timeOutTime;
}
long startTime;
long scheduledTimeout;
}
{code}
I agree it will be challenging to work out when to call this from readers etc
and how to estimate completeness but as a general utility class (as you
suggest, in o.a.l.util ) it seems like a useful addition.
My suspicion is that this is currently "contrib" - but then
TimeLimitingCollector is currently in core.
Maybe TimeLimitingCollector could be rewritten to use ATM and then we maintain
a common generally reusable implementation?
> 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, 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
