-
Bug
-
Resolution: Fixed
-
P2
-
e6u10, 6, 6u14
-
b93
-
b02
-
generic, arm
-
generic, linux
-
Verified
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2184397 | 6u17-rev | Alan Bateman | P2 | Closed | Fixed | b06 |
This bug is for tracking purposes.
jdk6 (and also updates to at least 6u14) allow a STPE to terminate where there is a periodic task and the policy is set to continue executing periodic tasks. This is demonstrated by the following test (which is based on http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/test/tck/ScheduledExecutorTest.java). The bug does not exist in jdk5 or jdk7 builds.
import java.util.concurrent.*;
public class Test {
static final ThreadFactory daemonThreadFactory = new ThreadFactory() {
@Override
public Thread newThread(Runnable r) {
Thread t = new Thread(r);
t.setDaemon(true);
return t;
}
};
static class NoOpRunnable implements Runnable {
public void run() { }
}
public static void main(String[] args) throws Exception {
ScheduledThreadPoolExecutor pool =
new ScheduledThreadPoolExecutor(1, daemonThreadFactory);
pool.setContinueExistingPeriodicTasksAfterShutdownPolicy(true);
pool.scheduleAtFixedRate(new NoOpRunnable(), 2, 2, TimeUnit.SECONDS);
pool.shutdown();
boolean terminated = pool.awaitTermination(10, TimeUnit.SECONDS);
if (terminated)
throw new RuntimeException("terminated??");
}
}
Recently we were running JCK on 6u14 b03 (64bit) on SLES11 x64 in a Virtual Box.
It appears that
api/java_util/concurrent/ScheduledExecutor/index.html#ScheduledExecutor
api/java_util/concurrent/ScheduledExecutorSubclass/index.html#ScheduledExecutorSubclass
JCK tests more fail than pass in such config.
I was unsuccessfull with rerunning api/java_util/concurrent/ScheduledExecutor/index.html#ScheduledExecutor
even with -platform.concurrentShortDelay 5000
In such configuration failures are good reproducible since 1.6.0 fcs.
Switching from Vortual Box to real machine greatly reduces failure rate.
Failures were also more often on Ubuntu muchine in Virtual Box.
Since this all configurations will be supported, I'm rising priority of the bug.
To reproduce failures:
1. Install SLES11 64bit in Virtual Box.
2. Install 64bit jdk (for ex. to /export/jdk/jdk1.6.0_14)
3. Install JCK6b (for ex. to /export/JCK/JCK-runtime-6b)
4. Prepare a simple script to run a test:
#!/bin/bash
export JAVA=/export/jdk/jdk1.6.0_14/jre/bin/java
export CLASSPATH="/export/JCK/JCK-runtime-6b/classes"
OPTS=""
TEST="javasoft.sqe.tests.api.java.util.concurrent.ScheduledExecutorTest"
#TEST="javasoft.sqe.tests.api.java.util.concurrent.ScheduledExecutorSubclassTest"
TOPTS="-platform.concurrentShortDelay 2000"
$JAVA $OPTS -version
$JAVA $OPTS $TEST $TOPTS
Installed jck could be found at /java/re/jck/6b/promoted/latest/binaries/JCK-runtime-6b/
Test sources is at /java/re/jck/6b/promoted/latest/binaries/JCK-runtime-6b/tests/
Same situation with Xandros OS on Qualcomm device. See CR 6823412.
jdk6 (and also updates to at least 6u14) allow a STPE to terminate where there is a periodic task and the policy is set to continue executing periodic tasks. This is demonstrated by the following test (which is based on http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/test/tck/ScheduledExecutorTest.java). The bug does not exist in jdk5 or jdk7 builds.
import java.util.concurrent.*;
public class Test {
static final ThreadFactory daemonThreadFactory = new ThreadFactory() {
@Override
public Thread newThread(Runnable r) {
Thread t = new Thread(r);
t.setDaemon(true);
return t;
}
};
static class NoOpRunnable implements Runnable {
public void run() { }
}
public static void main(String[] args) throws Exception {
ScheduledThreadPoolExecutor pool =
new ScheduledThreadPoolExecutor(1, daemonThreadFactory);
pool.setContinueExistingPeriodicTasksAfterShutdownPolicy(true);
pool.scheduleAtFixedRate(new NoOpRunnable(), 2, 2, TimeUnit.SECONDS);
pool.shutdown();
boolean terminated = pool.awaitTermination(10, TimeUnit.SECONDS);
if (terminated)
throw new RuntimeException("terminated??");
}
}
Recently we were running JCK on 6u14 b03 (64bit) on SLES11 x64 in a Virtual Box.
It appears that
api/java_util/concurrent/ScheduledExecutor/index.html#ScheduledExecutor
api/java_util/concurrent/ScheduledExecutorSubclass/index.html#ScheduledExecutorSubclass
JCK tests more fail than pass in such config.
I was unsuccessfull with rerunning api/java_util/concurrent/ScheduledExecutor/index.html#ScheduledExecutor
even with -platform.concurrentShortDelay 5000
In such configuration failures are good reproducible since 1.6.0 fcs.
Switching from Vortual Box to real machine greatly reduces failure rate.
Failures were also more often on Ubuntu muchine in Virtual Box.
Since this all configurations will be supported, I'm rising priority of the bug.
To reproduce failures:
1. Install SLES11 64bit in Virtual Box.
2. Install 64bit jdk (for ex. to /export/jdk/jdk1.6.0_14)
3. Install JCK6b (for ex. to /export/JCK/JCK-runtime-6b)
4. Prepare a simple script to run a test:
#!/bin/bash
export JAVA=/export/jdk/jdk1.6.0_14/jre/bin/java
export CLASSPATH="/export/JCK/JCK-runtime-6b/classes"
OPTS=""
TEST="javasoft.sqe.tests.api.java.util.concurrent.ScheduledExecutorTest"
#TEST="javasoft.sqe.tests.api.java.util.concurrent.ScheduledExecutorSubclassTest"
TOPTS="-platform.concurrentShortDelay 2000"
$JAVA $OPTS -version
$JAVA $OPTS $TEST $TOPTS
Installed jck could be found at /java/re/jck/6b/promoted/latest/binaries/JCK-runtime-6b/
Test sources is at /java/re/jck/6b/promoted/latest/binaries/JCK-runtime-6b/tests/
Same situation with Xandros OS on Qualcomm device. See CR 6823412.
- backported by
-
JDK-2184397 STPE terminates when policy set to continue executing existing periodic tasks
- Closed
- relates to
-
JDK-6440728 ThreadPoolExecutor can fail to execute successfully submitted tasks as specified
- Closed