Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-6814989

STPE terminates when policy set to continue executing existing periodic tasks

XMLWordPrintable

    • b93
    • 6
    • b02
    • generic, arm
    • generic, linux
    • Verified

        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.

              alanb Alan Bateman
              alanb Alan Bateman
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved:
                Imported:
                Indexed: