[
https://issues.apache.org/jira/browse/LUCENE-2822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13001889#comment-13001889
]
Uwe Schindler edited comment on LUCENE-2822 at 3/3/11 6:35 AM:
---------------------------------------------------------------
{quote}
It's 2011.
We can use Java 1.5 now in core Lucene.
so why don't we just rip out the TimerThread and use System.nanoTime() ?
{quote}
One of our large customers used System.currentTimeMillies() in their own TLC
collector implementation, which led to a immense slowdown as then on every hit
you get a quite expensive system call to the kernel. This would not be more
efficient with nanoTime, as its still a system call (at least on lot's of JVMs
like on Windows).
So the thread is much more effective (its only reading a volatile field), so we
need some shutdown. Another idea is to change this collector to not call
nanoTime or currentTimeMillies on every hit (as hit collection should be fast),
to maybe do this only every 1000 hit. The granularity could be a ctor param.
This saves the thread and its still controlable how exact the measurement
should be. A default of 1000 or maybe 10000 should be fine. Of course on the
first collect hit (modulo 0) it should already check the timeout (because lots
of queries do most work before the collection of hits).
was (Author: thetaphi):
{quote}
It's 2011.
We can use Java 1.5 now in core Lucene.
so why don't we just rip out the TimerThread and use System.nanoTime() ?
{quote}
One of our large customers presenters used System.currentTimeMillies() in their
own TLC collector implementation, which led to a immense slowdown as then on
every hit you get a quite expensive system call to the kernel. This would not
be more efficient with nanoTime, as its still a system call (at least on lot's
of JVMs like on Windows).
So the thread is much more effective (its only reading a volatile field), so we
need some shutdown. Another idea is to change this collector to not call
nanoTime or currentTimeMillies on every hit (as hit collection should be fast),
to maybe do this only every 1000 hit. The granularity could be a ctor param.
This saves the thread and its still controlable how exact the measurement
should be. A default of 1000 or maybe 10000 should be fine. Of course on the
first collect hit (modulo 0) it should already check the timeout (because lots
of queries do most work before the collection of hits).
> TimeLimitingCollector starts thread in static {} with no way to stop them
> -------------------------------------------------------------------------
>
> Key: LUCENE-2822
> URL: https://issues.apache.org/jira/browse/LUCENE-2822
> Project: Lucene - Java
> Issue Type: Bug
> Reporter: Robert Muir
>
> See the comment in LuceneTestCase.
> If you even do Class.forName("TimeLimitingCollector") it starts up a thread
> in a static method, and there isn't a way to kill it.
> This is broken.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
