From: Kevin McMurtrie on
You're allocating memory, allocating threads, and probably loading
classes between your clock starting and the executor's clock starting.

Sun's Delayed interface is also badly flawed. It's a Comparable
relative to the current time so comparing X to Y produces a different
result than comparing Y to X. The time shifting scrambles the
PriorityQueue to some degree, especially on GC pauses. In your specific
case below, Sun has a workaround for the problem by casting the other
Comparable to an internal implementation class to compare absolute
times. There are other uses of ScheduledThreadPoolExecutor where it
can't do the cast and it makes a mess.


In article <op.vgl6betlw1eelo(a)msrvcn04.belkin>,
"Chris Seidel" <cseidel(a)arcor.de> wrote:

> Hi,
>
> i'm using a ScheduledExecutorService to schedule a task. The problem is,
> that the task gets execute about 10 - 20 percent too late, e.g. when I
> schdule it with 20 s delay, it gets executed after 24 s.
>
> Is this "normal"?
>
> Here is the testcode:
>
> package com.foo;
>
> import static junit.framework.Assert.assertEquals;
>
> import java.util.concurrent.Executors;
> import java.util.concurrent.ScheduledExecutorService;
> import java.util.concurrent.TimeUnit;
>
> import org.junit.Test;
>
> public class SchedulerTest {
> private ScheduledExecutorService s;
> private long executedAtMillis;
>
> @Test
> public void test1() {
> s = Executors.newScheduledThreadPool(1);
> final long currentTimeMillis = System.currentTimeMillis();
> long delay = 20000L;
> s.schedule(new Runnable() {
> public void run() {
> executedAtMillis = System.currentTimeMillis();
> }
> }, delay, TimeUnit.MILLISECONDS);
> try {
> Thread.sleep(delay * 2);
> } catch (InterruptedException e) {
> }
> assertEquals(delay, executedAtMillis - currentTimeMillis);
> }
> }
>
> When I use java.util.Timer everything is ok:
>
>
>
> @Test
> public void test2() {
> Timer t = new Timer();
> final long currentTimeMillis = System.currentTimeMillis();
> long delay = 20000L;
>
> t.schedule(new TimerTask() {
> @Override
> public void run() {
> executedAtMillis = System.currentTimeMillis();
> }
> }, delay);
> sleep(delay);
> assertEquals(delay, executedAtMillis - currentTimeMillis);
> }
>
> Thank you.
--
I won't see Google Groups replies because I must filter them as spam
From: Chris Seidel on
On Fri, 30 Jul 2010 03:03:54 +0200, Arne Vajhøj <arne(a)vajhoej.dk> wrote:

> Java can not really do much on a non-realtime OS.

OK, OK... but we are talking about many seconds or minutes difference, not
about milli- or microseconds!
This cannot be in a simple test where nothing runs besides this simple
test in the VM.
From: Chris Seidel on
On Thu, 29 Jul 2010 22:27:44 +0200, Daniel Pitts
<newsgroup.spamfilter(a)virtualinfinity.net> wrote:

> There is no guarantee of the latest it will run, only the earliest.

I know. But in my opinion there is absolute no reason for a CONSTANT
offset in percent between delay and execution. This is absolute weird.
From: Chris Seidel on
On Fri, 30 Jul 2010 10:57:50 +0200, Chris Seidel <cseidel(a)arcor.de> wrote:

> On Thu, 29 Jul 2010 22:27:44 +0200, Daniel Pitts
> <newsgroup.spamfilter(a)virtualinfinity.net> wrote:
>
>> There is no guarantee of the latest it will run, only the earliest.
>
> I know. But in my opinion there is absolute no reason for a CONSTANT
> offset in percent between delay and execution. This is absolute weird.

OK; I got it:

http://communities.vmware.com/thread/215461

Damned, so my Software will not run in VMWare!? :/
From: Lew on
Arne Vajhøj wrote:
>> Java can not really do much on a non-realtime OS.

Chris Seidel wrote:
> OK, OK... but we are talking about many seconds or minutes difference,
> not about milli- or microseconds!
> This cannot be in a simple test where nothing runs besides this simple
> test in the VM.

It cannot be, yet you observed it. This is the great conundrum, Grasshopper.

--
Lew