lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (LUCENE-2822) TimeLimitingCollector starts thread in static {} with no way to stop them
Date Thu, 03 Mar 2011 06:35:37 GMT

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


Mime
View raw message