[
https://issues.apache.org/jira/browse/LUCENE-997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12563632#action_12563632
]
Sean Timm commented on LUCENE-997:
----------------------------------
I could go either way on the System.currentTimeMillis() versus a TimerThread
issue. I agree nanoTime is the correct implementation when using 1.5.
It doesn't seem like on Linux running ntp it matters much either way. NTP
tries to perform smoothing and makes clock changes slowly over a longer period
of time when it can rather than have an abrupt change, but YMMV if your system
is having clock issues. On a really overloaded Windows box, the TimerThread
implementation will not behave well as demonstrated above. I can't speak to
any other platforms.
> Add search timeout support to Lucene
> ------------------------------------
>
> Key: LUCENE-997
> URL: https://issues.apache.org/jira/browse/LUCENE-997
> Project: Lucene - Java
> Issue Type: New Feature
> Reporter: Sean Timm
> Priority: Minor
> Attachments: HitCollectorTimeoutDecorator.java,
> LuceneTimeoutTest.java, LuceneTimeoutTest.java, MyHitCollector.java,
> timeout.patch, timeout.patch, timeout.patch, timeout.patch,
> TimerThreadTest.java
>
>
> This patch is based on Nutch-308.
> This patch adds support for a maximum search time limit. After this time is
> exceeded, the search thread is stopped, partial results (if any) are returned
> and the total number of results is estimated.
> This patch tries to minimize the overhead related to time-keeping by using a
> version of safe unsynchronized timer.
> This was also discussed in an e-mail thread.
> http://www.nabble.com/search-timeout-tf3410206.html#a9501029
--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
