[
https://issues.apache.org/jira/browse/LUCENE-1720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12832444#action_12832444
]
Mark Harwood commented on LUCENE-1720:
--------------------------------------
Thanks for the updates, Shai.
Agreed on removing the treemap comment..
As you suggest, their may be a low-level accuracy timing issue under heavy load
but for the typically longer timeout settings we may set this is less likely to
be an issue.
Related: I did think of another feature for ATM - timeouts will typically be
set to the maximum bearable value that can be sustained by the hardware without
upsetting lots of users/customers who need answers.
This setting is therefore a tough business decision to make and is likely to be
on the high side to avoid annoying customers (10 seconds? 30?).
The current monitoring solution only aborts at the latest possible stage when
the uppermost acceptable limit has been reached and expensive resource has
already been burned.
Maybe we could add a progress-testing method to ATM which can throw an
exception earlier e.g.
public void checkForProjectedActivityTimeout(float
percentActivityCompletedSoFar)
Clients would need to estimate how far through a task they were and call this
method periodically.
> 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
